Extracorporeal blood processing information management system

ABSTRACT

A blood component collection system with manipulation and optimization capabilities. Process parameters are derived from an input/configured predetermined blood component yield and which is based upon the maximization of at least one process parameter. Thereafter, the blood component collection procedure is performed with these derived process control parameters. Also, process parameters are derived from an input total procedure time from a maximized value for at least one of the other process control parameters so as to maximize blood component yield in this fixed time. Thereafter, the blood component collection procedure is performed with these derived parameters.

This case is a divisional of U.S. patent application Ser. No.09/797,325, filed Mar. 1, 2001, which claims the benefit of priority ofU.S. provisional patent application Ser. No. 60/186,123, filed on Mar.1, 2000.

BACKGROUND OF THE INVENTION

The present invention generally relates to the field of extracorporealblood processing systems and, more particularly, to providinginformation management and/or data manipulation and/or optimizationcapabilities to, in and/or with such systems.

The utilization of blood taken from donors and transfused intorecipients is well known for purposes of treating medical conditions.More recently, selected blood components have been separated andcollected from donated blood for subsequent transfusion into recipientsfor the more specific therapeutic benefits of those particular bloodcomponents. The primary blood components of current interest in manyseparation and collection technologies include platelets, red bloodcells, white blood cells, stem cells and plasma.

In the harvesting of blood components, blood is removed from a donorthrough a needle assembly or other blood access device and maythereafter be processed by centrifugation or other appropriateseparation techniques to isolate and collect the desired components.This procedure is often carried out very effectively in an on-lineprocedure wherein blood is removed from a donor, processed in andthrough a disposable extracorporeal fluid circuit to obtain the desiredcomponents, and the uncollected components thereafter returned to thedonor. Two illustrative blood component collection systems that providefor this type of on-line blood component collection procedure are theCOBE Spectra (Registered Trademark) and Trima (Registered Trademark)apheresis systems, which are commercially available from the assignee ofthe present application.

The yield of a particular collection of blood components from such aprocess is an important factor in the ultimate usefulness of thoseparticular components. For instance, in the United States a minimumyield is associated with a collected blood component product in orderfor that product to meet certain criteria and qualify for use as atransfusable blood component product. The COBE Spectra and Trimaapheresis systems presently accommodate for this requirement byprocessing certain donor biological data such as height, weight, gender,and platelet pre-count or hematocrit, together with pre-configuredand/or operator-input data such as the total procedure time, andsystem-related data such as the type of collection procedure (e.g.,single or double needle) and collection efficiency to generate certainprocess parameters such as the inlet flow to the apheresiscentrifugation device (including, for example, the combined flow ofwhole blood from the donor plus typically a flow of anticoagulant).These apheresis machines then generate a predicted blood component yieldfrom these data as well.

An additional consideration presently in the United States, for example,relating to blood component yield is that the yield is determinative ofthe product classification. With regard to platelets, a single plateletproduct is presently considered to be a collection of 3×1 011 plateletsand a double platelet product is considered to be a collection of 6×1011 platelets. If a collection is between 3×1 011 and 6×1 011 platelets,it is still considered to be a single platelet product. Thisclassification as a single or double platelet product is important toblood component collection facilities (e.g., blood banks/centers) sincea double platelet product may have a higher selling price than a singleplatelet product and may also have a greater benefit for therecipient/patient. The yield of a particular collection of bloodcomponents may also be a relevant consideration for certain therapeutictreatments (e.g., red blood cell or plasma exchanges).

Furthermore, advances in blood component collection technologies offerthe possibility of collecting multiple combinations of products from asingle donor. These products can be defined within a large range ofvolumes and contents. Add to this multitude of collection choices, amultitude of donors with differing physiologies, each being subject topotential variations in collection procedures to yield a potential verylarge plurality of choices of products to be collected, as may bedesired.

Still other important considerations relating to blood componentcollection systems relate to the donor and product demand. For instance,blood component collection facilities are not only experiencing anincrease in the overall demand for blood components, but the demand nowtypically varies between the blood component types as well. Moreover,the supply of donors is unfortunately inadequate in many cases, anddonor time constraints are becoming more prevalent. Furthermore,obtainable yields from a given donor may vary from one blood componentto another, i.e., one donor may be a better platelet source than a redblood cell source.

The result is a large number of variables which must preferably besimultaneously managed in order to meet the blood bank collection goalswhich will thus also satisfy the needs of the ultimate hospital or likecustomer. Computerized information systems are tools, which arebeginning to prove useful in assisting in controlling parts of bloodcollection processes. This will likely further impact, if not transform,how blood banking will be managed in the future. Computer informationsystems may prove important in aiding the provision of just-in-timesupply of products to meet customized demand for blood products andbetter satisfying the individual needs of patients and providers.Automated component collection systems will also allow for flexibilityin producing customized blood products in a just-in-time fashion frompotentially fewer donors to help meet the demands of patients andproviders.

In view of the foregoing, it should be readily understood that bettermanagement of the various aspects of blood component collectionprocesses and systems is increasingly desirable in providing preferredproduct collection and customer supply options.

SUMMARY OF THE INVENTION

The present invention relates in one application to a blood componentcollection system and the provision of management capabilities, whichmay include the incorporation of data manipulation and/or optimizationprinciples. Generally, the present invention preferably utilizes aninformation management system, which provides simplified donor datastorage and control as well as communications with actual bloodcomponent collection machines to both ease and optimize the set-up andoperation thereof. The principles of data manipulation and/oroptimization are further improved also, particularly in terms of theindividual donor, a given pool of donors, the particular blood componentcollection system, and/or the blood component product or products to becollected. For instance, the present invention may be adapted to providefor the collection of a predetermined quantity of at least onepredetermined blood component, or more typically the collection of suchblood components within a particular range in a “minimum” amount oftime, and/or for the collection of a “maximum” quantity of at least onepredetermined blood component in a fixed amount of time, all based uponcertain donor and/or blood center defined process conditions. Moreover,the present invention may be adapted to provide for blood componentinventory control by basing donor selection and/or collection procedureselection (in terms of the type of blood component to be collected) onblood component demand and/or existing inventory. In addition, thepresent invention may be adapted to provide for further donor managementby collecting that blood component type or types from the donor, whichprovides a maximum yield.

A preferred central computational, data storage, manipulation andcommunication system serving as the primary basis of the presentinvention is preferably a software-type of application run in tandemwith one or more hardware devices including, for example, a data inputdevice, a data storage device, a data manipulation device and one ormore communications devices which connect in data communicationrelationship one or more of such input, storage and/or manipulationdevices to at least one blood component separation and/or collectionmachine. The software application may be and in preferred form isoperable in/on a Microsoft (Registered Trademark) Windows (RegisteredTrademark) software platform (or a similar such system) that allowsblood donation center operators to prepare apheresis machines and donorsfor apheresis donations in an automated manner. The present system maypreferably have two primary components, a computation-manipulationapplication with associated software and devices, and a server systemalso including associated software and devices. Thecomputation-manipulation application is used by the blood center staffto perform data management and/or manipulation functions. The serversystem is used preferably to store data and to provide communicationswith the apheresis machines and/or other information systems. In atypical setting, one or more operators from different locations within asingle blood center and/or remotely from various disparate blood centers(and/or other sites) can communicate with a centralized server system toperform specific functions such as donor check-in, preparing a donor fora particular donation, or finalizing and/or preparing reports oncollection activities, inter alia.

An important purpose of the present system is to address variouschallenges in the area of blood donation management including increasingproductivity, better donor qualification/utilization and improvedproduct quality control and disposition.

Increased productivity may be accomplished through centralizedmanagement of apheresis machine configurations. Operators and/or systemadministrators may easily create and store several configurations usingthe present system on a centralized server/computer or a likeenvironment. These configurations are preferably kept in a centralizeddatabase and can be downloaded to each apheresis machine on a permanentor a temporary/one-time donation basis. This reduces the inherentcontemporary difficulty of editing apheresis machine configurations byallowing the operator to update a centralized configuration and not berequired to repeatedly make the same change on several stand-aloneapheresis machines.

Donor qualification/utilization may be improved through procedurecustomization and/or optimization. Each donation may be customized bythis system to account for the current needs of a blood center and/oroptimized by what each particular donor is eligible/qualified for orcapable of donating. This allows the operator to determine what productor combination of products will best be collected even before the donoris connected to the machine. It also allows the blood center operatorsto see what tubing set is required for the donation. With thisinformation the customer can avoid wasting tubing sets and reduceincomplete procedures. Decision support for donor eligibility is apreferred beneficial feature of the system. At a minimum, eligibilitymay be determined by the interval between donations, the number ofdonations previously given, the blood component loss over a period oftime, and other donor screening issues.

Another important, yet optional feature of donorqualification/utilization and management in using a system of thepresent invention involves donor recruitment. The present inventionprovides a tool that may analyze and predict donation outcomes prior torunning a donor on an apheresis machine. Such a tool can use donor andprocedure information from the central database or optionally from animported text file containing the required minimum information. Thus,such predictions can be used independently of actual runs on donors,even those actual runs involving the system of the present invention.These predictions may also be independent of procedures not currentlyentered into the central database, but rather from data generated by theblood center or data obtained from the blood center information system.Donor data may refer to a particular donor or to a statisticaldistribution of donor population. At a minimum, the system of thepresent invention may preferably analyze the outcomes of the followingthree scenarios: a) a single donor relative to many possible procedures;b) many donors relative to a single type of procedure; and c) manydonors relative to many possible procedures.

Improved product disposition may be enhanced through the provision ofalterable prioritizations of the product needs of a blood center. Thepresent system presents the capability of providing a prioritization ofwhich products are preferred to be collected. This allows the bloodcenter to begin to incorporate the concept of demand drive where donorsare used to fill existing and/or imminent product needs. This alsoreduces waste from the over collection of certain products. The systemalso presents the capability to tailor a blood center's priorities byblood type, CMV status, and/or HLA type matching.

The present system also provides for quality control (QC) in the entryof laboratory data for products collected by blood separation devicesoperated in accordance with the present invention. Data may include (butis not limited to) measured yields, volumes, concentrations, productcontaminants, and pH levels. The present system provides the capabilityto associate anomalous QC lab data to donation events and to generateexception reports where the device prediction and QC lab results maydiffer. The present system can also utilize this data to automaticallycalculate and adjust a separation device's yield calibration value,i.e., a yield scaling factor, depending on the particular device type.

Overall procedure and apheresis machine management may also be improvedby recording procedure history information for each apheresis donationand storing it in a central database. Thus, the system may contain adetailed log of each donation. These logs can include procedurecomments, tubing sets used, alarms experienced, adjustments made, andmachine run summary information. Operators may additionally annotatethis procedure history information and/or obtain reports using suchlogged information.

To implement the above and other features of the present invention, itis preferred that a central computational/data storage system beestablished according to the present invention so that it communicateswith each of one or more blood collection machines, preferably apheresismachines, in both directions (even though one-way communications may bedesirable in certain situations). Two way communications provide fordirecting to each machine configuration information of both temporaryand permanent natures, procedural lists and priority information, donorvital information, including height, weight, gender, blood componentpre-counts and total blood volume (TBV), as well as donor identificationwhich may include a donor picture with the donor's name and perhaps thedate of birth. The centralized system may then also communicate in thereverse direction with each machine to retrieve from each apheresismachine immediate information regarding conditions such as alarms,procedure adjustments, and run progress (product collection information)for monitoring purposes. It also provides for retrieving end of runsummary information and run logs after each procedure is complete. Thecentralized system can also use data from the apheresis devices todetect and isolate potential maintenance problems before they manifestthemselves to the blood center. These can then be reported so thatpreventive maintenance may be performed.

The present system preferably uses prediction algorithms like those usedin the COBE Spectra and/or Trima apheresis machines. Moreover, theprediction algorithms can also be applied to individual donors, areference donor list, and/or ranges of donors within the database. Thiscapability is helpful to predetermine donor eligibility for specificproduct collections, and what products would be available given specificapheresis machine configuration settings.

The present system has been developed with an open architecture toprovide integration capabilities and collaborative capabilities withother computing environments (such as Mak and/or Wyndgate donor databaseinformation systems) and/or with other component separation machines(such as the Haemonetics and/or the Baxter series, e.g., the MCS+(Trademark) and/or the Amicus (Trademark) and/or CS-3000 (Trademark)apheresis machines, inter alia). This ultimately will allow ancillaryapplications to be used. For example, this allows for the manipulationand formatting of donor identification data and/or images obtained fromother information or software systems. Bar code capability is anotherpreferable alternative, which may be incorporated into the presentsystem. Any field entry point which could/would require keyboard dataentry could be filled using a bar code reader. In addition, specialentry fields such as unit or batch number, manufacturer and expiry datesof disposable tubing sets may be fully decoded utilizingadministratively editable decoding information; an example ismanufacturer identification of a disposable tubing set.

Products can also be customizable from a collection standpoint. This isa potential first step toward a “dosing” model whereby components may becollected in quantities matching specific medically or doctor prescribeddoses. These customizable products, although perhaps not directly donorspecific, could also be set up in a way to take care of situations suchas a “first time” donor or persons known as “lumpers,” i.e., thosepersons whose component products show a certain tendency to clump oraggregate.

After determining which product or products are to be collected, eachdonor can be assigned to a specific apheresis machine. Monitoringreal-time machine status from a central system is useful to determine towhich machine each donor should be sent.

The present system has been designed to satisfy an optional yetdesirable three room operational flow scenario. The basic three roomscenario involves processing donors sequentially through three stepswhich may correspond to three different rooms; namely, donorregistration or reception, donor interview/screening and donorutilization rooms. This model has been suggested for providing smoothoperation of the blood component collection process.

During or after the run, numerous standard reports may be made availableto provide the donation center information related to specific runs,sequences of runs, exceptions, etc. Although the reports are preferablystandardized, customization may also preferably be made possible throughthe simple use of report wizards. The present system preferably alsoutilizes an industry standard report engine.

The central database provides the system with the capability of storingand maintaining data relevant to the entire blood component collectionprocess such as, donor demographic information, machine configurationinformation, run information and lab result information. Lab data canalso be entered into the run record to complete the product collectionrun record. This data can be used to provide feedback to the process.The communication software and hardware enable the pulling of data fromand transmission of data to a common or central data repository.

This system may be used in a stand-alone configuration or incollaboration with a blood banking information system, especially fortransfer of donor demographics and like donor identificationinformation. The blood center information system is preferablyconsidered the master when linked. Fire wall protection may be providedthrough password protection schemes, message formatting requirementsand/or hardware communications interfaces. This provides the assurancethat the integrity of the apheresis machine is maintained duringconnectivity of this system with such machines(s) and/or with othersystems. The present system can also utilize a “standard” customernetwork for communications between a central system server andoperators. This concept of collaborative networking particularly withpre-existing networks can minimize the “re-wiring” that otherwise mighthave been necessary.

Connectivity may also be utilized to provide collection data to theblood bank information system after the run is complete. This two-waycommunication strategy allows the present system to optimize theprocedure and device selection based on the blood center's currentpriorities, rather than making these selections less-optimally at donorregistration time. The as-run collection data may also synchronize theblood bank information system to the actual products, yields, andvolumes donated.

Further, this system preferably utilizes formal and de-facto standardssuch as SQL interfaces to the database, ethernet protocols forcommunications, and preferably Oracle (Trademark) reports for reportgeneration.

In the present system, an apheresis machine, which is preferably alsooperable in an off-line mode, may upload run information to a centralserver system when the apheresis machine is connected on-line with thecentral server system. This feature could also be used for mobile orsatellite operations.

An additional preferred functionality is connectivity with a bloodcenter information system. Donor data will preferably be down-loadableto the central server system of the present invention from the bloodcenter information system. This will allow real time updating of donordata in the central database of the present invention from the databaseof the blood center information system. Other alternatives of thepresent system may also include connectivity of the central datamanipulation and/or storage system to apheresis machines from aplurality of manufacturers.

Of the various methods of data transfer available, an option is a webserver set-up. With specially developed applets, this allows the localuser or a remote user (with permission) to browse the operator'sdatabase for pertinent information. Thus, this system can also beaccessed remotely and provides an external “gateway” to run-logs fromeach apheresis machine. Security can be established to obscure sensitivedata. An administration/security optional feature would allow the systemto be configured with the concept of user types for security. A systemadministrator would have the most privileges and a guest would have theleast number of privileges.

The present system provides an opportunity to circumvent shortcomings inthe operational procedures forced on a blood center by the use ofpre-existing blood bank software. Specifically, the present system mayovercome the problem of a blood bank software system pre-selecting bloodcomponents to be collected rather than having the present system performthis selection process. The way this is achieved is unique in that datais exchanged with the blood bank software system during the process flowof information. This is different from having either system depend oninputs from the other system and then wait for outputs.

The present invention also preferably may be characterized as a bloodcomponent collection system having blood component product-based ortime-based optimization capabilities. One embodiment comprises a methodfor collecting at least one predetermined blood component (e.g., acollection of platelets or red blood cells or plasma) from a source ofwhole blood using a blood component collection system, which includes ablood component collection device running according to a particularcollection procedure. More particularly, a desired yield of thepredetermined blood component(s) may be identified (such yield includinga single yield or range of yields) and biological data relating to thesource of whole blood is provided to the blood component collectionsystem. This data may also include statistically developed modificationsbased upon categories of data for multiple sources of whole blood ascontained within the central server systems. Also, a value or magnitudemay be associated with each of the various process parameters used inthe collection procedure. A magnitude of at least one of these processparameters is preferably derived from the biological data and thedesired yield and optionally also the statistically derived data from aplurality of whole blood sources. These magnitudes, including allmagnitudes of process parameters derived from the desired yield, areinput to the blood component collection system. Thereafter, thecollection procedure is performed with the blood component collectiondevice and with the input process parameters to collect the desiredyield of at least one predetermined blood component(s) from the wholeblood source.

In a time-based optimization method, a total procedure time for thecollection procedure is identified (e.g., based primarily upon donortime availability). One potential inlet flow to the system is derivedfrom at least this identified total procedure time. Another potentialinlet flow to the system is derived which provides an “optimum”collection efficiency and is effectively the apex of a bell-shapedyield/inlet flow curve (i.e., the inlet flow which provides the maximumblood component yield). Consequently, if the total procedure time-basedinlet flow is greater than the maximum yield-based inlet flow, and thusis an inlet flow on the decreasing slope portion of the yield/inlet flowcurve, the maximum yield-based inlet flow magnitude is used in theperformance of the collection procedure. However, if the total proceduretime-based inlet flow is less than the maximum yield-based inlet flow,and thus is an inlet flow on the increasing slope portion of theyield/inlet flow curve, the total procedure time-based inlet flowmagnitude is used in the performance of the collection procedure.

The subject invention provides greater efficiency in blood componentcollection and management. For example, the present invention can beused to compare blood bank/center component inventories with projectedneeds, and adjust collection procedures to meet these needs. Further,the present invention provides benefits to donors. In particular,certain information relating to the donor's physical and medicalcharacteristics may be stored in the system and utilized duringsubsequent visits by the donor to derive magnitudes for the variousprocess control parameters. For example, for a donor with ananticoagulant intolerance, the magnitude of the anticoagulant infusionrate may be set so as to not exceed the donor's tolerance.

The present invention may be implemented as a computer process, acomputing system or as an article of manufacture such as a computerprogram product. The computer program product may include a computerstorage medium communicatively connected to and/or readable by acomputer system and may include encoding of a computer program ofinstructions for executing a computer process. Such a computer programproduct may also be a propagated signal on a carrier readable by acomputing system and may also include encoding of a computer program ofinstructions for executing a computer process.

These and other features of the present invention can be betterunderstood from the following detailed description of a preferredembodiment of the present invention taken in conjunction with theaccompanying drawings, which are briefly described below.

BRIEF DESCRIPTIONS OF THE DRAWINGS

FIG. 1A is a schematic representation of a blood processing informationmanagement system in accordance with principles of the presentinvention.

FIG. 1B is another schematic representation of a blood processinginformation management system in accordance with principles of thepresent invention.

FIG. 1C is yet another schematic representation of a blood processinginformation management system in accordance with principles of thepresent invention.

FIG. 1D is still another schematic representation of a blood processinginformation management system in accordance with principles of thepresent invention.

FIGS. 2A-2I are display screen depictions of data entry, retrievaland/or manipulation display pages for use in accordance with the presentinvention.

FIGS. 3A-3F are further display screen depictions of data entry,retrieval and/or manipulation display pages for use in accordance withthe present invention.

FIGS. 4A and 4B are still further display screen depictions of dataentry, retrieval and/or manipulation display pages for use in accordancewith the present invention.

FIGS. 5A and 5B are yet still further display screen depictions of dataentry, retrieval and/or manipulation display pages for use in accordancewith the present invention.

FIGS. 6A through 6M are another set of display screen depictions of dataentry, retrieval and/or manipulation display pages for use in accordancewith the present invention.

FIG. 7A is a schematic representation of one embodiment of a bloodcomponent separation assembly which utilizes a dual needle configurationand which may be incorporated into the blood component collectionsystems of FIGS. 1A-1D.

FIG. 7B is a schematic representation of one embodiment of a bloodcomponent separation assembly which utilizes a single needleconfiguration and which may be incorporated into the blood componentcollection systems of FIGS. 1A-1D.

FIGS. 8A and 8B are isometric and top views, respectively, of one typeof a disposable blood processing channel which may be used in the bloodcomponent collection device of FIGS. 7A and 7B.

FIG. 9A is a flow chart of a blood component collection procedureutilizing principles of the present invention.

FIG. 9B is a flow chart of one optimization model for deriving at leastone optimal process parameter from a desired blood component yield orfrom a total procedure time in accordance with principles of the presentinvention.

FIG. 9C is a flow chart of one optimization model for deriving at leastone optimal process parameter from a desired blood component yield orfrom a total procedure time in accordance with principles of the presentinvention.

FIG. 10 is a yield/inlet flow curve.

DETAILED DESCRIPTION OF THE INVENTION

The present invention will be described with reference to theaccompanying drawings, which assist in illustrating various pertinentfeatures hereof. One application of the present invention involves oneor more blood component collection systems which separate, remove, andcollect at least one type of blood component (e.g., platelets, red bloodcells, stem cells, white blood cells, plasma) from a source of wholeblood (e.g., a donor) through utilization of a collection procedurederived from a typically site-configured and/or operator-input goal orset of goals and may optionally also include a “maximization” of atleast one process control parameter. This type of maximized parameterderivation is referred to herein as an “optimization process” and thederived process control parameters may be referred to herein as “optimalvalues.”

Referring to the schematic of FIG. 1A, a first alternative schematicrepresentation of the present invention is shown as including a bloodcomponent collection and information management system generallyidentified by the reference numeral 2. The system 2 would typically beimplemented at a blood bank/center (not shown in FIG. 1A). The system 2may include a substantially centralized computing/data storage assembly140 (e.g., including an appropriate microcomputer and/or microprocessorsuch as a Windows-based standard desktop or laptop computer (or otherlike platforms), including therein or communicating with at least onememory device, not shown separately in FIG. 1A, with correspondingappropriate software, etc.) and at least one blood componentseparation/collection assembly (three shown), each generally identifiedwith respective reference numerals 10 (in FIGS. 1A-1 D). Each suchseparation collection assembly 10 preferably includes a blood componentseparation and collection device 18 as an integral part thereof. As willbe discussed below, the centralized computing/data storage assembly 140(or at least a portion thereof) and the associated blood componentcollection assemblies 10 are preferably appropriately interfaced witheach other in electronic or electro-magnetic data communicationrelationship as will be described, but may also and/or alternatively bedisposed in a physically separate disposition from each otherparticularly during non-communication operation. That is, componentseparation/collection, data communication, retrieval, manipulation, andoptimization procedures in accordance with principles of the presentinvention are not limited to being performed at any particular physicallocation of apheresis machines 10 relative to a central assembly 140.Furthermore, data entry, manipulation and storage may still be performedat/on each machine 10 using, for example, respective interfaces, whichhere are shown as preferred touch screen input/output devices 199.

A further aspect of the present invention is shown in more detail inFIG. 1B wherein a centralized computing/data storage assembly 140 isshown schematically disposed in communicative relationship with varioustypes of blood component collection machine assemblies 10 as well as toeither a discrete blood center information system within a blood center1000 or a hospital information system within a hospital 1001, or both.Thus, as will be described in further detail below, a centralizedcomputing/data storage assembly 140 may preferably make broad use ofmultiple communication connections (including satellite and/or wide areanetworks (WAN's), for example). Note also that though preferableconnections to Trima apheresis machines 10 (available from the assigneeof the present invention) are shown and described throughout; these areintended as exemplars only. As shown in FIG. 1B, connections can be madeto numerous other machines as well, such as COBE (Trademark) Spectraapheresis machines and/or Baxter, Inc. and Haemonetics Corporationapheresis machines (such as the CS-3000, the Amicus and the MCS+apheresis machines, inter alia). The currently preferred machines 10are, as shown, Trima apheresis machines 10 (see e.g. FIGS. 1A-1D).However, a representation of a COBE Spectra apheresis machine is alsoshown in FIG. 1B, identified therein generally by the reference numeral10A, and a Baxter Amicus machine and a Haemonetics MCS+ machine are alsoshown in FIG. 1B and identified by the respective reference numerals 10Band 10C. Use with a more traditional manual whole blood collectionsystem is also shown schematically in FIG. 1B, generally identified bythe reference numeral 10D, therein. Thus, this system is intended to andwill operate with various apheresis as well as whole blood collectionsystems.

Generally, a centralized computing/data storage assembly 140 mayinclude, as shown schematically in FIG. 1A, a central station 148 whichmay include, for example, data input/entry devices generally identifiedby the reference numeral 149. Such devices 149 may, more particularly,include a keyboard 149A, a mouse 149B, and/or if desired, devices suchas a barcode reader (not shown), and/or a digital camera (not shown)and/or an input/output display monitor and screen 200 as these may beknown in the art. Various internal hardware and software elements, againas known in the art are also intended to be included within a centralstation 148. Further, the centralized computing/data storage assembly148 may include a data manipulation device 144 (disposed within station148 in FIG. 1A), which is preferably closely associated with and in someembodiments is perhaps inseparable from the central station 148.Manipulation device 144 may be an appropriate processor as used in acomputer system such as may be used in a microcomputer or otherwisestandard desktop or laptop personal computer (PC) including a preferablyWindows-based operating system and may further include other devices andattendant manipulation software (whether resident on/in the processor orresident in other associated memory devices but closely associated withthe processor). A further preferred element of the computing/datastorage assembly 140 is the storage medium 142 (not separately shownfrom central station 148 in FIG. 1A) used for data storage. The storagemedium 142 may also be closely associated with the other elements of theassembly 140, i.e., the central station 148 and the manipulation device144, or as with those other devices it may be dissociated in physicalspace but communicatively associated therewith through space (viacabling or energy wave communications, inter alia), so long as theseelements cooperatively interact functionally. Hardware and softwarewhich may make possible data communication between various elements ofassembly 140, as well as between assembly 140 and myriad possibleexternal devices, some of which are like those shown in FIGS. 1A and 1B,are hereafter referred to as a communication or server subsystem 146.Subsystem 146 may also be mainly disposed on or in the assembly 140and/or may be mostly physically disparate therefrom so long as itprovides the data communication functions described herein.

Thus, the assembly 140 may be referred to as a whole for performance ofthe inputting and maintaining of donor-related data functions(principally through use of the central station 148, communicationsubsystem 146, and the storage medium 142), and also typically for thepreparation of an initial procedure order (the process controlparameters derived from the donor-related data and other considerations)for a given donor (through use primarily of the data manipulation device144 together with the data obtained from either or both of the otherelements 148,142 as communicated by and through the subsystem 146).

Though perhaps not preferred, there may remain various situations inwhich it may be desirable to maintain the ability to perform data entryand/or manipulation procedures/functions at the correspondingpre-existing operator interface 199 of each particular apheresis machineassembly 10 as well. In such situations, a central computing/databaseassembly 140 may thus not be required for operation of assembly 10 evenif still provided. Note in the preferred apheresis machines 10 shown inFIG. 1A (such as the Trima machines 10 described above), thecomputing/database and data entry and manipulation capabilities areavailable in and would thus be able to continue to separately providethese functions, if desired. Moreover, this could still occur even whenconnected through a central communications system 146 to a centralassembly 140 such that the computer/database assembly 140 may stillcollect/retrieve data from the one or more apheresis assemblies 10 evenif the central assembly 140 is not used to program the respectivemachines 10. However, where a central computing/database assembly 140 isemployed as preferred herein, this donor-related data and/or initialprocedure order is preferably generated by the central computer/databaseassembly 140 and then transferred to one of the apheresis machines 10(via an RS/232 or other similar interface, among other communicationsoptions such as energy wave communications, inter alia (see furtherdescriptions below)). In either event, the operator is preferablyprovided with one or more data manipulation or optimization options,whether through the central data manipulation device 144 of acentralized computing/data storage assembly 140 or the data manipulationcapabilities of the apheresis machines 10 themselves. Note the datamanipulation and/or optimization options provided by a central assembly140 may provide a different set of process control parameters than aninitial procedure order that might result from data entered manually onthe apheresis machine 10 because the data manipulation and/oroptimization on a central assembly 140 may be based upon one or morepreviously specified and central database stored conditions/goals (e.g.,input blood component yield, input procedure time) and one or moreparticular derivations for the process control parameters. Generally,more flexible options would be available from a central server system140 than those previously available on discrete machines 10. Moreover,if an optimization option is selected at the central server 140, amanually-entered procedure order may be modified to reflect the resultsof such an optimization and the collection procedure may be initializedor re-initialized with the results of the optimization (i.e., thecollection procedure could be re-initialized in the less preferred caseof an optimization which is performed after the collection procedure hasbeen started and such a case is referred to as a downstreamoptimization). The collection procedure may thereafter be performed bythe respective blood component collection device 10.

The concept of optimization here generally refers to achieving themaximum or best product output depending upon certain circumstances(e.g., obtaining the most product in a certain specified time orachieving a specific yield in the fastest time). On the other hand, theconcept of data manipulation is more generally here intended to have asimilar yet less exacting connotation, such that perhaps the best ormaximum output may, but will not necessarily be the result. Thus, datamanipulation is here intended to encompass optimization calculations inaddition to providing perhaps less than optimum but still highefficiency results depending on certain further combinations ofcriteria. Thus, data manipulation is intended to generate more and/orperhaps better options to the blood donation center. For example, bloodcenters may prefer or determine to require certain combinations ofproducts from certain blood type donors 14 (see FIG. 1B); then the bloodcenter 1000 can prioritize this in the computer/database 140 so thatthose donors will donate those combinations even if the particularyields or donation times are not fully optimized according to theconcept of optimization set forth above. Thus, yield or timeoptimization can be made secondary to other data requirements and/ormanipulations. Note also that optimization and/or manipulation may beperformed without requiring the central system 140 to collect/retrievedata from the various apheresis assemblies 10. Thus, communications maybe made only one-way to (or from) the apheresis assemblies 10. Further,a preferred purpose for performing the optimization and/or manipulationfunctions centrally is to allow selection of the donation procedureprior to connection of a donor to a machine 10; thus, a particularproduct or products and the corresponding tubing set (if there aredistinctive such sets) may be selected prior to machine set-up and donorconnection. Also it could prove that the donor may not be able toprovide a useful donation (for the end recipient/patient 15; see FIG.1B), and this could thus be determined prior to machine set-up and/ordonor connection.

Nevertheless, before describing the preferred manipulation/optimizationprocesses of the present invention in any further detail (seedescription relative to FIGS. 7-1 0, below), two further, non-exhaustivealternative system embodiments will first be described. Referring firstto FIG. 1C, an alternative centralized computing, communication and datastorage assembly 140A is shown. Assembly 140A includes a centralstation, here referred to as a central data server 148A, which may besubstantially like the central server 148 in FIG. 1A, at leastpreferably in primary function. At least a storage medium/database 142Aand preferably also a data manipulation device 144A, each againsubstantially like those described relative to the embodiment of FIG. 1Aare also preferably disposed within the central server 148A of FIG. 1C.However, in the embodiment of FIG. 1C, the communication sub-systemidentified generally by the respective reference numerals 146A and 146B,is shown as preferred here discrete therefrom, in two general sub-parts,referred to respectively as the machine network 146A and the clientnetwork 146B.

Machine network 146A preferably includes a network terminal server 1210with a connection 1212 between the server 148A and the terminal server1210. Respective connections 1215 are also shown as disposed betweenterminal server 1210 and each of the separation/collection machines 10.Connections 1212 and 1215 may typically be RS/232 cable-typeconnections, or other alternative data communication connections may beused including such options as radio, microwave or other electromagneticwave communication systems (not specifically shown). Note that otherseparation/collection machines/systems, such as systems 10A, 10B, 10Cand 10D (from FIG. 1B) may also be connected to/through the illustratedterminal server 1210 or a further discrete server (not shown).

A similar, though preferably discrete, network terminal server 1220 isalso shown in FIG. 1C to illustrate a preferred communication sub-systemfor the client network 146B. A connection 1222 between the centralserver 148A and the terminal server 1220 is also shown, as arerespective connections 1225 from the terminal server 1220 to one or moredata input/output/manipulation stations 149C (two shown here).Connections 1222 and 1225 may here also typically be RS/232 cable-typeconnections, or take other data communication forms including, forexample, energy wave communication forms. Note also that other devices(not shown) might also be connected or connectable to/through theillustrated server 1220, as for example, one or more printers (notshown) or other accessory devices. Note, stations 149C may contain, asabove, one or more various input/output devices such as keyboards, miceand/or screens (as shown) or otherwise (barcode readers, digitalcameras, etc., not shown). Moreover, as decentralized stations, theseassemblies may also generally include computing devices and/orcapabilities such as may be included in standard desktop or laptopcomputers, including the stations 148B as shown, and potentially datastorage/memory and/or data manipulation devices and/or software alongwith potential resident communications devices and/or software.

Separating the machine network server 146A from the terminal networkserver 146B allows for isolating and/or protecting communicationstherebetween, as may be desired. Thus, the respective servers may haveon one side, a network connection to the central server 148A usingdiscrete I/P (Internet Protocol) address information, and on the otherside, RS/232-type connections to the respective end devices (machines10, and/or input/output devices 149C, e.g.). In this fashion then, eachnetwork may be kept private from each other such that the I/P's areessentially hidden from each other by the central server 148A. Afirewall communication protection setup as known in the art may thus beestablished.

A further alternative communication sub-system 146C is shown in FIG. 1D.Sub-system 146C generally includes a network terminal server 1230 withrespective connections 1232 which connect respective central servers148C to network terminal server 1230. RS/232 or other communicationconnections (as above) may be used here as well. In this way, two ormore centralized servers 148C may communicate data with each other.Thus, central servers in two or more physically separate clinics maycommunicate with each other. Such a system may also be used forcommunication with other information systems (blood center informationsystems or hospital information systems) such as is schematically shownin FIG. 1B. Other similar communications can also be made in this way,as for example to help or maintenance centers (not shown), as describedbelow. Firewall types of communication protections may also be set uphere, such as was described above. Thus, network connections can be madebetween each central server 148C and the network terminal server 1230;whereas RS/232-type communications can be established elsewhere. Note,all variations of system 140 may include communications connection(s) ofmany different sorts, which allow each particular device to communicatewith other devices. RS/232 communications connection(s) as described,are only examples of such communication media. Communication media maytypically embody, be embodied in or otherwise be capable of interactingwith and/or through computer readable instructions, data structures,program modules or other data in a modulated data signal such as acarrier wave or other transport mechanism and include any informationdelivery media. The term modulated data signal may include a signal thathas one or more of its characteristics set or changed in such a manneras to encode information in the signal. By way of example, and notlimitation, communication media may include wired media such as a wirednetwork or direct-wired connection, and wireless media such as acoustic,RF, infrared and other wireless media. The term computer readable mediaas used herein preferably includes both storage media and communicationmedia.

A more detailed description of the preferred steps for using the presentpreferred system will now be set forth. In FIGS. 2A-2I, inter alia; useof the centralized computing/data retrieval assembly is shown in moredetail. First, FIG. 2A depicts an exemplary display page or screen 201which may be the first such screen displayed on the output monitordisplay screen 200 (see, e.g. FIG. 1A) of the centralized computing/datastorage assembly or system 140 when the software thereof is initiallyaccessed. A more, rather blank, screen (not shown) may be used as aninitial screen upon startup, as described below. As can be seen indisplay screen 201 generally, the initial donor information may begathered here, such as for example the donor's name (last and/or first),and/or the donor's identification (ID) number or like identifier (ifused), and/or the donor's telephone number or other identification data(also if used, not shown). Data entry fields for these types of data maybe seen in the main work area 202. These are several examples ofpossible initial identifiers among numerous others, which could bealternatively substituted herein.

Moreover, as mentioned this could be the first display screen to beshown upon software initialization, or other alternatives (not shown)could be simply used preliminarily hereto by way of introduction to thisor a like display 201. In any event, some display is preferably used asthe starting point for data entry (and/or search, if the data werepreviously entered or imported from another system) for use with aparticular donor, and for the sake of convention, display 201 will beused in this role for this description of the preferred embodiment. Notealso, that as shown in FIG. 2A, disposed next to the main work area 202(with sub-areas 203 and 204 as will be described below) is a procedureicon selection area 205, which is depicted along a vertical portion ofthe left-hand side of display 201. In it, five icons 207, 208, 209, 210,and 211 are currently shown, though either more or fewer such iconscould be used as may be desired.

A description of the preferred general overall procedural flow will beset forth starting with particular reference to the procedure icon bar205 on the left side of the display screen 201.

As an initial step or sub-procedure, the Select Donor icon 207represents the performance of several functions generally described asfollows. First is a Greet Donor function wherein the system operator mayverify and/or add a new donor record to the system database 142, andcheck-in a donor into the system 140 (either by data entry directly intothis application or via automatic transfer of data from a discrete bloodbank information system). Thus, the operator may perform DonorEntry/Edit functions to enter or modify a donor record in the database(see e.g., FIGS. 2B-2I, as described below). This may also includecapturing a donor image using a digital camera to take the donor's photo(this functionality may also or alternatively be part of the PrepareProcedure Wizard process; see below). And, this may include use of abarcode reader to enter bar-coded data such as the donor ID, etc. (Note:this data input functionality may also be part of other processes inthis system such as the Prepare Procedure Wizard (entering bar-codedunit number) and/or the Finalize Procedure Record (entering bar-codedlot number/data for supplies).)

After the data entry/verification, the next general step wouldpreferably be to Prepare the Procedure for component collection asindicated by the second icon 208 in bar 205 as shown in FIGS. 2A and 3A,inter alia. This preferably involves using a Prepare Proceduresub-procedure or software wizard to record further donor information andselect the procedure to be run on the donor prepared as set forth above(see description relative to FIGS. 3A-3F, below).

Next, the operator preferably uses the Assign Machine icon 209 to accessthe sub-procedure for assigning the donor to a particular apheresiscollection system 10. More details of this process are described belowwith particular respect to FIGS. 4A and 4B.

As shown generally in FIG. 5A, the central system 140 may be used formonitoring the procedure/machine status after the assignment of a donorto a particular machine. An icon 210 (FIGS. 2A and 5A) is preferablyincluded for accessing this functionality in the left-hand procedureicon area 205. Screen 501 (FIG. 5A) reflects the first step in such amonitoring sub-procedure. Finalization of the Procedure Record may alsobe performed here, wherein the operator may enter procedure data,including operator roles and supplies entries. (Note: this recordfinalization functionality may also be part of the Select Procedureprocess below.)

Another optional step in the overall procedure shown in FIGS. 2A and 6Aby the icon 211 is the Select Procedure sub-procedure where the operatormay search for and select a procedure (either active, pending, orfinalized). A screen 601 such as shown in FIG. 6A may then be displayed(as described in further detail below). The operator will then be ableto enter lab results by entering procedure product volume/qualityinformation returned from the lab. The operator may finally prepare aReport on the Procedure by generating procedure or donor or productionreports.

It ought to be noted that the various sub-procedures identified by therespective icons 207-211 can be selected at any time in the overallprocedure to view, input or modify particular desired information. As anexample, but not to be considered in any way as a limitation, the assignmachine icon 209 could be selected at anytime to view the list ofavailable and/or assigned machines 10. However, it should be noted thatcertain functionalities may thus be unavailable if an icon 207-211 isselected without having completed a previous sub-procedure. For example,upon selection of the assign machine icon 209 as suggested here, theassignment function will not be available unless at least one donor hasbeen processed though the Prepare Procedure sub-procedure (seedescription, below). In such a case, where no donor has yet been soprocessed, there would not appear any donor icon in the donor assignmentqueue of screen 401 (FIG. 4A), even if the available and assignedmachines 10 may be shown in the machine list. Similar functionalitiespreferably requiring pre-completed sub-procedures (thus building onprevious module completions) are identified throughout the belowdescriptions.

Although not a part of the general run procedure (and thus not involvingor resulting from the clicking of icons in the procedure icon area 205),Administration Tasks (extra security being preferably required to accessthese options) may generally include: Setting Up the Applicationincluding setting default values; setting the apheresis machineconfiguration(s) including creating and/or modifying apheresiscollection system configurations; Defining Products includingestablishing an unlimited number of product definitions; DefiningProcedures including establishing an unlimited number of proceduredefinitions (combinations of product definitions); Defining Focus Listsincluding establishing an unlimited number of procedure focus lists(prioritization of procedure definitions); Performing DatabaseAdministration including managing and maintaining the data stored withinthe central database; and Blood Product Prediction wherein a bloodproduct forecasting report may be generated.

Returning now to FIG. 2A, a more detailed description of the preferredoverall procedure will now be set forth. In an initial start-up mode ofsoftware initialization, the main work area 202 could be adapted todisplay a preliminary display screen (not shown), which has no activeworkspaces. Then, after log-in (see below), the operator could be forcedto select an icon from a menu list and/or from the left-hand procedureicon selection area or bar 205 in order to initialize the overallprocedure. As an example, the operator could first select the selectdonor icon 207 with a computer screen cursor or pointer (not shown) andclick the “enter” or mouse button (neither shown) as is known in the artof standard desktop or laptop computer, Windows-based or like softwareapplications. This selection could then bring up the shown display 201for beginning a donor check-in procedure. A few further alternatives foruse in start-up (as well as throughout operation) may be found in thetoolbars located as shown horizontally along the upper portion of thedisplay 201. These are toolbars much like those used in a plurality ofcomputer Windows-type software applications with numerous functionalsimilarities and specific distinctions as described herein. For example,the software start-up to the initial working display may also beachieved by selecting the “Tasks” menu heading 216 in the top level menutoolbar 215 and then selecting the appropriate “open” file command (notshown) or other like commands as are generally known in the art. Or,similarly, a small icon toolbar 217 may be configured to be used forinitiating software procedures, as may also be generally known in theart. Other menu headings and/or icons (not shown) in toolbars 215 and/or217 (or otherwise, not shown) may be used for other functions in startupor otherwise.

A third toolbar 220 may further be used in or even prior to softwareinitialization or it may not be opened until the main work area 202 hasbeen opened. The third toolbar 220 as shown and preferred herein has alocation for the typing of a name or other identifier which may be usedto begin the process of either data entry for new records or a searchfor existing records. This third toolbar 220 is preferably used foridentifying the operator of the system, such identification being usefulfor logging-in and/or assessing the operator's level of securityclearance, inter alia (described below). Thus, it is preferred that thisoperation of logging-in the operator be completed first. Further, it ispreferred that a system administrator have previously establishedauthorized users, with log-in names and optional passwords. The log-innames may then be typed in the blank space in tool bar 220, or the downarrow may be selected and clicked to reveal the list of authorized usersto be selected. Once a user log-in name is entered, then a pop-up dialogbox/window (not shown) may be made to appear to prompt entry of anappropriate password. Note, password and/or user log-in names may bemade editable via such a pop-up dialog box/window (not shown) or may berestricted to editing by a system administrator. Further similar optionsmay also be used for these initialization procedures as may be known inWindows or Windows-like environments.

Returning now to the main work area 202 of the display screen 201, twosub-areas 203 and 204 are shown in which data may be entered ordisplayed. First, as shown in sub-area 203, data concerning the identityof the donor to be checked-in may be entered in order to begin thedonation process. The computer/database system 140 may then be made tosearch its database 142 (by selection of the search button 218 by theoperator) to determine whether this particular donor has been previouslyentered in the system. If so, the system 140 returns the results of thatsearch in the search results sub-area 204. Note that the search may bemade dependent on any of the criteria set forth in the first sub-area203 (or others not shown herein but alternatively usable herewith).Also, the search mechanism may be adapted to search wild cards and/ortruncated terms or list various short forms for further search as theseand other search capabilities are known in the art. As such, when typedinto the proper field, this display screen simply calls up a donor fromthe existing database if such a donor exists therein. A search/queryformat may be used wherein typing an alphabetical initial will call upinto the results window 204 all donor names beginning with that initial.The operator may then double click on a listed name to select and callup the next preferred screen (see FIG. 2B, the donor entry/edit screen221), which contains greater detailed donor information as will bedescribed below.

First, however, several other graphical buttons are shown in the mainwork area 202 of FIG. 2A and may be used to perform various functions.For example, below the work sub-area 204 are examples of three buttons,which could be set forth on this or any other alternative display screenused herein. In this example, the three buttons here are the “new”button 212, the “select” button 213 and the “help” button 214. The “new”button 212 could be used to toggle to a fresh search page like this one201 shown without any information in any of the fields (name, ID, orresults). Alternatively, the “new” button 212 could allow for either newdata entry editing directly in the fields shown here in screen 201, orcould be used to call up a secondary display screen, such as the DonorEntry/Edit screen 221 shown in FIG. 2B (described below). Such a “new”screen would preferably have empty fields to allow for new donorinformation data entry. Note, the “new” button 212 is shown in active,darkened mode in FIG. 2A as compared to the other “grayed-out” buttons213 and 214. This means it is active as shown (and as would beunderstood to those knowledgeable in the art of common, conventionalWindows and the like software applications). It is active as shown whenit may be desirable to enter new data records into the system. The“grayed-out” “select” button 213, on the other hand, is inactive until asearch result record is displayed in sub-area 204. When such a record ismade available, button 213 would be made active and darken in style suchas the other active buttons shown here. The “select” button 213 providesfor the selection of a donor data record to be verified and/or modifiedfor preparation of a collection procedure. This functionality as well asthat of the “help” button 214 is described in greater detail below.

As next shown by the donor data entry/edit screen 221 in FIG. 2B, datacan be either manually input into the computer/database system 140 bytyping into the corresponding fields such as will be described furtherbelow. Or, any appropriate data input can be performed with analternative input system such as, for example, a bar code reader (notshown), or input from other computerized information systems as will bedescribed below and/or become obvious to those skilled in the art. Ifusing a bar code reader, a donor may be given a donor identification(ID) card which may have a bar code imprinted thereon which representsthat particular donor's data. Then, an optical reader (not shown) can beused by the operator to read the bar code information from the card tofill in the donor data fields shown in FIGS. 2B-2I. The other previouslyintroduced alternative input process would be in taking advantage ofother pre-existing database/information systems which may alreadycontain the appropriate donor data. Thus, the present computer/databasesystem 140 may be disposed in data communication relationship with oneor more such pre-existing systems and simply upload the desired datatherefrom. Thus, the fields such as those shown in FIG. 2B, et al., canbe automatically populated from the blood center's managementinformation system (e.g., Wyndgate, MAK, etc.). In this situation, thereception portion of the data entry process (i.e., initial data entryand/or verification) could take place entirely on the blood centerreceptionist's computer in the corresponding Wyndgate or MAK (or like)system. This information may then be retrieved by and/or forwarded tothe computer/database system 140 to populate the fields such as thoseshown in the display 221 of FIG. 2B. This display 221 may be referred tohereafter as the Donor Entry/Edit screen 221 and may, in the three-roommodel, initially be called up in what may be referred to as the“Reception” room. This three-room model will now be briefly described.

There may be considered three main data input/verification points in acollection process. At the first point, hereafter referred to as“Reception,” the donor is checked into the overall process. Under ascenario of data connectivity between the central computing/databasesystem 140 and a blood bank information system, the “Reception”room/step may be handled through the blood bank information system andthe needed donor data may then be automatically transmitted (downloadedor uploaded or otherwise) into the central system 140 as describedabove. With this connectivity between the blood center informationsystem and the central system 140, the historical donor data (which maybe batch file loaded into the central system 140 periodically) may alsobe called up and the donor may then be assigned to the second room,hereinafter also called the “Screening Room.” In the screening room thedonor information may be retrieved and displayed and several preferablepieces of lab data may be input for purposes of selecting theproper/preferred collection procedure to be performed. A donation unitnumber may also be assigned at this point. The central system 140 may,but preferably does not, hold confidential donor information influencingpotential deferral; this information would preferably reside only in theblood bank information system. The central system 140 is preferably onlyconcerned with the collection process. In either the “screening room” orthe third room, hereinafter also called the “Donation Room,” the donormay be assigned to a particular apheresis machine. The proceduresperformed in the donation room may also include recording other dataabout the procedure such as recording the identification numbersassociated with the disposable tubing set. Once the donor is assigned toa machine, the central system 140 would preferably go into amonitor-only mode relative to that donor and that machine for monitoringand/or recording any and/or all events in the procedure. More detailshereon are provided below.

Returning to the donor entry/edit screen 221 of FIG. 2B, further detailsconcerning some of the specific, preferred fields, tabs, buttons, etc.shown on screen 221 in FIG. 2B will now be set forth.

As mentioned, new donor records may be created using screen 221, andpre-existing records may also be edited/modified here. A primarydifference in creating new records versus modifying existing ones liesin the fact that the fields shown in FIG. 2B will be empty prior toentry of new record information, as opposed to having been populated bypreviously entered (or imported) data in the modification sense. Asshown in FIG. 2B, the data fields are primarily populated thus generallysignifying either a data import or previous donor record entrysituation.

Primarily donor identification data/information, such as the donor'sname and/or ID, may be entered/edited in the fields disposed preferablyin an upper substantially fixed area 222 of screen 221. However, if thisdata has come from a previously entered record, the fields in area 222are preferably “inactive” as shown by being “grayed-out.” Thus, thesefields would preferably not be editable directly, rather would beeditable otherwise as described below. Other information about aparticular donor may then be entered/edited in corresponding fieldsappearing with respective tabs in the lower data area 224. For example,donor demographics information may be entered/edited in correspondingfields under the “Demographics” tab 231 as shown in FIG. 2B. Othergeneral information such as gender or date of birth, inter alia, wouldpreferably be enterable/editable under the “General” tab 241 (see FIG.2C). Blood type, CMV, (cytomegalovirus) and HLA (Human LeukocyteAntigen) type, inter alia could be entered/edited under the “History”tab 251 (FIG. 2D). A “Comments” tab 261 (FIG. 2E) could be selected andused for entry of comments about the donor. Allergy information could beentered or edited under an “Allergies” tab 271 (see FIG. 2F). Donorstatus data could be entered and/or edited under a “Status” tab 281(FIG. 2G) including such data as, for example, last procedure date,numbers of donations given, over what period of time, etc. Other tabs,such as a “Blood Loss History” tab 291 (FIG. 2H) and/or a “ProcedureHistory” tab 299 (FIG. 21) could also be used for separate entry of suchinformation. Note, separate pop-up dialog boxes or other alternativescreen styles or types (none shown) may be used for prompting for andentering/editing these types of information.

Note, the information shown and described here in screen 221 mayalternatively be optional or mandatory, depending on the desires of theultimate user; here, usually a blood center. That is, the standardoperating procedures (SOP's) of the blood center may be implementedherein to make certain information optional or mandatory, as desired.However, certain information, whether listed here (under the DonorEntry/Edit screen 221) or entered elsewhere (see the Prepare Procedurefunctionality, described below) may be required by the bloodseparation/collection assembly 10 prior to initiation and/or completionof a separation/collection procedure. Examples of such information maybe gender, height, weight, blood type, and/or pre-count (plateletsand/or hematocrit) information (again, see the Prepare Procedure,below). As such, some of this information (e.g., height/weight) wouldonly be enterable/editable, as preferred here, in the procedurepreparation portion of the overall process (see below).

Moreover, as introduced above, all, most, or at least the informationrequired by the blood center may be entered or have been enteredpreviously into the blood center's separate (but communicatively-linked)information system (not separately shown, but see FIG. 1B). Such aninformation system is separate from the present invention, althoughthese systems may be made to communicate with each other. Thus, suchinformation may be entered into the blood center information system,preferably according to the standard operating procedures (SOP's) of theblood center, and then this information may be transferred (downloadedor uploaded, or otherwise) to the central system 140 of the presentinvention. This information would then populate the respective fieldsshown and/or described here relative to the Donor Entry/Edit screen 221.An operator of the present system may then use screen 221 to merelyverify the accuracy and/or completeness of this information shown onscreen 221 prior to checking-in the donor for the present collectionprocedure.

In a presently preferred embodiment, when a blood center informationsystem is used, the transmission of this general sort of donoridentification, demographics and commentary information, inter alia, isone-way from the blood center information system to the central serversystem 140 of the present invention, primarily to maintain SOP's onwhich types of donor information a blood center may wish to capture.Thus, the operator may continue to operate at reception in a fashionunchanged from before introduction of the present invention.

Nevertheless, these donor identification data may also be transmittedboth ways; namely, from the blood center information system to thecentral server 140 and/or back to the blood center information systemfrom the central server 140. In such an option, these data may beentered/edited in either system and then be made to update the recordsof the other system. Note, these donor data communications are discussedhere only in terms of the general donor data; not necessarily includingfeedback information about the results of any particular collectionprocedure. Such procedural data communications are also consideredwithin the present invention, but are discussed further below.

First however, more particular descriptions of the preferred data to beentered/edited in screen 221 will now be described.

As mentioned, in the Demographics tab 231, the operator may enter/modifythe donor's national ID, address and telephone number as shown in FIG.2B. Then, after selecting the General tab 241, the following informationmay preferably be entered/edited: Gender (Male or Female, neither ofwhich preferably selected by default); Date of Birth (which can be typedin text box or selected using pop-up calendar); Ethnic Background(preferably available via a drop-down list which is editable byselection only, and is preferably created by the System Administrator);and Donor Picture (the default is preferably a generic, genderless icon;however, if a gender is selected using one of the Gender radio buttons,this icon preferably changes to a gender-specific icon the next time thedonor record is accessed, provided the operator saved the data beforeclosing the dialog box). The operator can optionally click UpdatePicture to take donor's photo using an optionally attached digitalcamera.

The operator may then optionally click the Donor History tab 251 (FIG.2D) to view/modify procedure history data for this donor. This tab 251may contain the following information: Blood Type, CMV, HLA, Hematocrit,and/or Platelet Count. More specifically, the Blood Type may include A+,A−, B+, B−, AB+, AB−, O+, O−, or Unknown; preferably accessible via adrop-down list, editable by selection only; default is preferablyUnknown. The CMV Status includes Unknown, Positive, and Negative Radiobuttons options; the default is preferably Unknown. HLA Typing optionsare as follows: the operator may select the HLA Tested check box if HLAtesting has been done for this donor; or left unchecked by default. Andthe A, B, C, D check boxes are disabled unless the HLA Tested check boxis selected. Once HLA Tested is selected, the operator can select one ormore HLA-type check boxes (A, B, C, and/or D). The Last Hematocrit andthe Last Platelet Count are preferably non-editable, generallypre-populated fields from past procedure data or external blood bankinformation system, if available.

The operator may then also optionally click the Comments tab 261 (FIG.2E) to enter/view free-form comments about the donor. To add a comment,the operator clicks the Add Comment button 262. A separate Enter DonorComment pop-up dialog box (not shown) may then appear, or comments maybe made enterable/editable within the work space 263, shown. Theoperator may then enter a comment in the text box. Note that a commentis preferably not saved in the donor record until the operator clicksthe Apply or OK button 229 or 230 in the Donor Entry/Edit dialog box 221(see more details below).

The operator may then optionally click the Allergies tab 271 (FIG. 2F)to enter/view donor allergies and associated comments. To view thecomments about a specific allergy, the operator clicks the allergy inthe Donor Allergies list; associated comments for this allergy appear ina Donor Allergy Comment box. To add an allergy, the operator may clickthe Add Allergy button. An Enter Donor Allergy pop-up dialog box (notshown) may then appear. A listing of allergies (preferably non-editableand created by the System Administrator) may be made to appear in such adialog box and the operator may optionally enter a comment pertaining tothat allergy in the Allergy Comment box. Note that an allergy ispreferably not saved in the donor record until the operator clicks theApply or OK button 229 or 230 in the Donor Entry/Edit dialog box 221(see details below).

The operator may also decide to remove an allergy from the DonorAllergies list. The operator may then click the allergy in the DonorAllergies list, and then click the Remove Allergy button. The allergy isremoved from the displayed list; however, the allergy is not permanentlyremoved from the donor record until the operator then clicks Apply or OKbutton 229 or 230. The operator may decide to enter additional commentsfor an allergy currently in the Donor Allergies list. The operatorclicks the allergy in the Donor Allergies list, and then clicks the AddComment button. An Allergy Comment dialog box (not shown) may be made toappear. The operator can then enter a comment and click an OK option.The Donor Entry/Edit dialog box 221 reappears, still showing theAllergies tab 271 (FIG. 2F). The allergy listing in the Donor Allergieslist is updated to show the new comment. The date and time the commentwas created, as well as the user ID for the user who was logged on whenthe comment was created, will preferably appear with the comment in theDonor Allergy Comment box.

The operator may then optionally click the Status tab 281 (FIG. 2G) toenter/view the following donor status information: Donor Status—Activeor Inactive; Donor Category (a drop-down list, preferably created by theSystem Administrator); Donor Since Date—date the donor started donating(preferably defaults to first procedure date, if not modified, which canbe typed in text box or selected using a pop-up calendar); Last VisitDate—last date the donor attempted to donate (defaults from systemrecords, preferably non-editable except by the System Administrator);Last Procedure Date—the last date the donor actually did donate (defaultfrom system records, non-editable except by the System Administrator);Last Contact Date—last date that the center contacted the donor (can betyped in text box or selected using pop-up calendar, default ispreferably the current date).

The operator may then optionally click the Blood Loss History tab 291(FIG. 2H) to view the total volume of blood the donor has lost fromapheresis (not whole blood) activities for the previous 12-month period.All of the data in this tab is preferably non-editable in this module.It is downloaded as run data from the apheresis collection system 10(preferably a Trima system 10) for procedures run for this donor, and/orentered by an operator during procedure finalization (see below). Thetab 291 preferably shows the Total Blood Loss the total volume(preferably in milliliters) of blood the donor has lost from apheresis(not whole blood) activities for the previous 12-month period); and aProcedure table which shows blood loss for apheresis procedures forwhich a procedure record exists in the central server system 140. Eachprocedure is preferably listed in a separate row in the table. Theoperator may need to scroll horizontally or vertically to view some ofthe data. For each procedure, the table preferably shows the following:

Procedure Date—The date the procedure was run.

Product RBC—The volume of RBC product collected during the procedure(total RBC volume less anticoagulant volume). This information ispreferably determined based on the procedure that was run and thedonor's hematocrit.

Sample RBC—The volume of sample RBCs collected during the procedure.This volume is either the default value set by the Administrator duringsystem setup or a value entered by an operator during procedurefinalization, according to the facility's SOPs (see the FinalizeProcedure Record description below).

Residual RBC—The volume of residual RBCs remaining in the tubing setafter the procedure. This information is determined based on the tubingset type, the procedure that was run, the donor's hematocrit, andwhether or not rinseback was completed for the procedure.

Other RBC—Any other RBC volume (for example, estimated volume of aspill), entered by the operator in the Finalize Procedure Informationdialog box, Blood Loss tab, according to the facility's SOPs. (see theFinalize Procedure Record description below).

Product Plasma—The volume of plasma product collected during theprocedure (total plasma volume less anticoagulant volume). Theinformation is determined based on the procedure that was run and thedonor's hematocrit.

Sample Plasma (not shown in FIG. 2H; scrolled off the right side of thescreen)—The volume of sample plasma collected during the procedure. Thisvolume is either the default value set by the Administrator duringsystem setup, or a value entered by an operator during procedurefinalization, according to the facility's SOP's (see the FinalizeProcedure Record description below).

Residual Plasma (not shown in FIG. 2H; scrolled off the right side ofthe screen)—The volume of residual plasma remaining in the tubing setafter the procedure. This information is determined based on the tubingset type, the procedure that was run, the donor's hematocrit, andwhether or not rinseback was completed for the procedure.

Other Plasma (not shown in FIG. 2H; scrolled off the right side of thescreen)—Any other plasma volume (for example, estimated volume of aspill), entered by the operator in the Finalize Procedure Informationdialog box, Blood Loss tab, according to the facility's SOPs. (See, theFinalize Procedure Record description below.)

The operator may then optionally click the Procedure History tab 299 toview product information for all procedures run for this donor since thedonor record was created in the present system 140. The tab 299 showsproduct information only for apheresis procedures for which a procedurerecord exists in the database 142. All of the data in this tab ispreferably non-editable. It is downloaded from the apheresis system(preferably a Trima system) 10 run data for procedures run for thisdonor. The operator may need to scroll horizontally or vertically toview some of the data. For each procedure, this tab 299 preferably showsthe following:

Procedure Date—The date the procedure was run.

Platelet Yield—The yield of platelets collected during the procedure.

Plasma Volume—The volume of plasma collected during the procedure(plasma product volume plus anticoagulant volume).

RBC Volume—The volume of RBCs collected during the procedure (RBCproduct volume plus anticoagulant volume).

Various alternative data entry/editing actions may also be preferred.For example, at any time while using the Donor Entry/Edit dialog box221, the operator may click the Apply button 229 (see FIGS. 2B-2F, e.g.)to save all to-date changes to the donor record, without exiting thedialog box. Similarly, at any time while using the Donor Entry/Editdialog box 221, the operator may click the Cancel button 228 to cancelthe current entry session. The system 140 may then prompt the operatorto confirm the cancellation. If cancellation is confirmed, the systemmay lose all unsaved changes and closes the Donor Entry/Edit dialog box221. A Help button 227 is preferably also provided to present acorresponding help screen (not shown) when desired.

If the facility determines that a donor record no longer needs to be inthe central database 142, the record can be permanently removed. Thisoption is preferably only available when an operator with a high levelclearance such as a System Administrator user role or the like is loggedon to the system. This Administrator or high level operator may thensearch for and display the donor record in the Donor Entry/Edit dialogbox 221, as described and then click the Remove button 226 (see e.g.,FIG. 2B). A warning may first be made to appear, informing the operatorthat the record will be permanently removed from the database 142. Ifremoval is still desired a Yes confirmation button (not shown) may beselected. The following may then occur: 1) both the warning message andthe Donor Entry/Edit dialog box 221 may be closed; 2) the Search Resultsbox 204 in the Select Donor task window 201 (see FIG. 2A) would nolonger show a listing for the removed donor; 3) the donor record wouldpreferably be permanently removed from the database; and/or 4) aninternal record for this donor may be retained elsewhere in the systemfor reporting reasons.

Moreover, at any time while using the Donor Entry/Edit dialog box 221,the operator may change the donor's name, while retaining the currentdonor ID. To do so, the operator would preferably click the Edit DonorName button 223 (see e.g., FIG. 2B) in the Donor Entry/Edit dialog box221. An Edit Donor Name dialog box (not shown) would preferably be madeto appear, displaying all previous names used by the donor, as well asthe date the name was changed and the operator who was logged on to thesystem when the name change was made. The operator may then enter a newname for the donor in the Last Name, First Name, and/or Middle Nameboxes, and conclude with an OK option (not shown). The Donor Entry/Editdialog box 221 would then reappear, showing the changed name. Theoperator can still also decide to not change the name by selecting aCancel option in the Edit Donor Name dialog box (not shown) to retainthe current donor name; whereby, the Donor Entry/Edit dialog box 221would reappear, showing the unchanged name. Note that a changed name isnot saved in the donor record until the operator clicks the Apply or OKbutton 229 or 230 in the Donor Entry/Edit dialog box 221.

Similarly, at any time while using the Donor Entry/Edit dialog box 221,the operator may change the donor's ID, while retaining the currentdonor name. To do so, the operator would click the Edit Donor ID button225 (see FIG. 2B) in the Donor Entry/Edit dialog box 221. An Edit DonorID dialog box (not shown) would preferably be made to appear, displayingthe current donor ID. The operator could then enter a new ID for thedonor in the New Donor ID box, and click an OK button (not shown) tosave the ID change. The Donor Entry/Edit dialog box 221 reappears,showing the changed ID. The operator can also decide not to change thedonor's ID, and click a Cancel option in the Edit Donor ID dialog box(not shown) to retain the current donor ID; in this case, the DonorEntry/Edit dialog box 221 would again reappear, showing the unchangedID. Note that a changed ID is not saved in the donor record until theoperator clicks the Apply or OK button 229 or 230 in the DonorEntry/Edit dialog box 221.

At any time, the operator can search for and select the record for anydonor who is already checked in to the system. However, if the donor isalready checked in to the system, the following fields, inter alia, inthe Donor Entry/Edit dialog box 221 may be preferably disabled andtherefore cannot be modified: General tab: Gender; History tab: BloodType; Status tab: Donor Status.

Once the appropriate/desired donor data is satisfactorily entered,edited and/or verified using screen 221 (FIGS. 2B-2I), the donor maythen be checked-in to the next step in the process, the PrepareProcedure step/sub-procedure (described below). Donor check-in may beaccomplished from any view of screen 221 by clicking the “OK” button 230(or another appropriately labeled button, e.g., “Check-in” if soprovided, not shown). This may then send the donor information to thePrepare Procedure portion of the software application (e.g., to thePrepare Procedure software module, if the software is so modulized as ispreferred). Alternatively, a pop-up dialog box (not shown) can be madeto appear for confirmation that donor check-in is desired. “Yes” or “No”options may be provided in such a pop-up dialog box to confirm theoperator's desires. Clicking the “Yes” option will then pass the donorinformation to the Prepare Procedure Step, as described. Note, clickingthe “No” option will provide for not passing the donor information tothe next procedural step; however, it may be made to either save alledited/entered information while exiting the Donor Entry/Edit screen221, or it may be made to call up a further pop-up window to confirmwhether the edited/entered information should be saved to the centralmemory 142 before exiting the Donor Entry/Edit screen 221. Note alsothat, as will be described below, the donor data entered/edited viascreen 221 may be made further enterable/editable at later stages of theoverall procedure after initial check-in, still preferably through useof a screen 221, or the like. Thus, provision (preferably throughclicking the Select Donor icon 207 in bar 205; see FIG. 2A) may be madeto return to screen 221 or the like at later stages of the procedure toenter new data or modify existing data, as may be desired. However, atsuch later stages, a check-in option would not preferably be madeavailable if (as would be true in such a situation) the donor had/hasalready been checked-in. Thus, clicking the “OK” button 230 (see FIG.2B, e.g.) would only save the information to the donor record in memory142 and not proceed to a “Check-in” dialog box, if used (not shown).

FIG. 3A shows the next step in the overall general component collectionprocedure, which would appear after donor check-in is completed asdescribed above. This next step corresponds generally with the showndisplay screen 301 which would have been accessed via clicking on thePrepare Procedure icon 208 in the procedure icon area 205. This nextstep in the data entry/manipulation process shows, via the displayscreen 301, the donors who have been checked into the system and are nowready for selections of the desired collection procedures to beperformed. The work area 202 of screen 301 in FIG. 3A then preferablydisplays a listing of donors (via a text list (not shown) or byrepresentative icons as shown, or otherwise (not shown)), which havebeen checked-in according to the above-described procedures(s). Thisgrouping or listing of checked-in donors may also be referred to as a“donor queue.” A donor may then be selected from this queue by clickingthe corresponding icon 302 or 303, for example. Once the donor isselected in screen 301 (selection being indicated by distinctiveshading, see icon 303 in FIG. 3A), the next step can be accessed byclicking the “Prepare” button 304 in the main work area 202, or, in anoptional embodiment, by again clicking the “Prepare Procedure” icon 208in the icon area 205. Note, a “Remove” button 305 could alternatively beselected to remove the donor from the Checked-in Donor Queue, (i.e.,from the work area 202) if desired. Also, help may be obtained at anytime by selection of the “Help” button 306. Note, in a preferredembodiment, the donor icon(s) 302 and/or 303 may include the donor'sphoto (i.e., as introduced above, the computer/database system 140 mayalso be equipped with a digital camera as is known in the art ofcomputer systems generally).

There may be at least two general and perhaps overlapping preferencesfor separating the Donor Check-in functionality from the PrepareProcedure functionality. Specifically, a first such preference mayderive from the three room scenario suggested/described above, wherein adonor may be greeted by a receptionist or receptionist-type of operatorin a “Reception” room or area. Then, the donor information describedgenerally above (see FIGS. 2A-2I, e.g.) may be entered and/or editedand/or verified at such a “Reception” point of the overall procedure.The donor may then be moved to a second, discrete room where a second,discrete operator may perform the Procedure Preparation steps describedhereinbelow. These rooms/areas may be separate physically or rather maynot actually be separate at all, depending upon the blood center and itspreferred operating procedures and facility arrangements. The operatorsmay also not be discrete; however, the second, likely overlappingpreference for the functionality separation may be that there are twoseparate operators and the second operator may have different technicalskills and/or qualifications from the first operator, i.e., the secondoperator may be qualified to run the actual collection procedure whilethe first, reception operator/person may not. Thus, by separating thesefunctionalities (even if the “rooms” are not separated), the receptionperson or the reception area computer may be given access limited onlyto the Select Donor icon functionality, for example. At the same time,the perhaps higher qualified collection operator may be relieved of thedata entry/edit tasks associated with initial check-in procedures.

As a result of finishing the previous steps (data entry modification anddonor check-in), the Prepare Procedure portion of the overall processmay be performed next. As shown in FIG. 3B, a “Prepare Procedure”sub-procedure, preferably a “Prepare Procedure” Wizard, as depicted by afirst Wizard display screen 321, may substantially automatically leadthe operator through the procedure preparation process. Note, a wizardas known in the art generally, may be a software module or sub-procedurewhich includes a series of screens used to accomplish a particular taskor operation. Note, this “Prepare Procedure” wizard screen and/or othersuch screens (as follow) may be sub-windows or full window-sizeddisplays.

In particular, as shown here, respective screens 321, 331, 341, and 351of respective FIGS. 3B, 3C, 3D, and 3E represent substantiallysequential wizard screens accessed initially by the selection of the“Prepare” button 304 (after selection/highlighting a particular donoricon, e.g. icon 303) of screen 321 in FIG. 3A. These wizard screens321-351 are then sequentially accessed; one to the next, by theselection of the respective “Next” buttons 322 (see lower portions ofscreens in FIGS. 3B and 3C, e.g.). Backtracking, in reverse order, ofthese wizard screens is also available by selection of the respective“Back” buttons 323, disposed preferably adjacent the “Next” buttons 322.Other general wizard buttons such as the “Help” button(s) 324, the“History” button(s) 325 and the “Cancel” button(s) 326 may be selectedat any general point in this process to obtain respectivelyassistance/information, a history of data entry/edits (and/or optionallydisplayed screen views 321-351, e.g.) and/or to cancel the PrepareProcedure wizard at any time.

Further details of preferred process for using these preferred and likescreens will now be set forth.

The operator is presented with the first page of the “Prepare Procedure”module/wizard/sub-procedure, the Donor Identification page 321 as shownin FIG. 3B. This page shows the donor's name, donor ID, date of birth(DOB), and photo (if previously taken and/or saved in the database 142).This page allows the operator to confirm the donor's identity and,optionally, to take or update a photo of the donor. An “update picture”button 328 may be supplied for providing a new or updated photo. Fieldspecific behavior of these items is preferably as follows: the “DonorName is pre-populated with first and last name from the donor recorddata, and is preferably not editable here. The “Donor ID” is alsopre-populated, and preferably not editable. The “Date of Birth” field ispre-populated using localized format, and not editable. And, the“Donor's photo” is also preferably pre-populated to further assist theoperator confirm the proper donor is present for this procedure beingprepared. If such a photo is not available for this particular donor, ageneric male or female icon may be displayed. The operator may thenclick the “Next” button 322 to proceed to the next page of the wizard.

A Unit Number text box 329 may also be disposed in either of screens 321or 331 (or elsewhere, see FIG. 3B). A Unit Number is preferably arequired field entry. The operator may enter the unit number either bytyping the number in the Unit Number box 329, or by using a barcodereader (not shown, e.g., by highlighting the unit number field 329 andthen using the bar code reader to scan the supply bar code which wouldthen populated this field 329). The unit number may be supplies relatedinformation or taken therefrom as related to the tubing set type used,or the bag identifiers to be used. The Directed Donor and HLA matchedboxes 330 are further alternative fields which could be entered/editedat this (or a later) stage of the procedure. These fields are directedto noting whether this donor is providing a donation for a specificpre-identified recipient, and the HLA match box merely records whetherthe HLA types have already been matched for such a directed donation perpre-existing techniques. The operator may then click the Next button 322to proceed to the next page, or the Back button 323 to return to theprevious page.

Then, as shown by the display screen 331 in FIG. 3C, gender, height,weight, hematocrit and platelet pre-count parameters will preferably beentered, if not already populated in the respective fields 332, 333, 336and 337 as previously entered in and thus disposed in the database 142.In fact, even if these parameters are previously entered, these fieldsin this screen 331 may be made mandatorily re-entered here, or at leastre-confirmed before the system 140 may allow the operator or donationprocess to proceed (note, if re-entered here, it may be that this datare-entry could rewrite the database information at this point or at theend of the collection process as part of the entire record which issaved to the central database 142 at that time). The other fields shownin this FIG. 3C are preferably entered as well, but may be madeoptional. As introduced above, and as will be understood from furtherdescription below, the required fields may be populated with historicaldata until the current lab values come back.

More particularly, the operator is presented with the Donor Informationpage 331 of the wizard, see FIG. 3C. Donor “vitals” are taken andentered on this page. The following items are preferably displayed onthe Donor Information page 331. The Donor's Gender is preferablypre-populated in field 332, required, and editable via selection: Maleor Female. The Donor's Height and Weight are preferably alsopre-populated (see fields 333) with the last value (from database 142,if available) in localized units, editable, and required. The valuewritten to the database will indicate if the value was changed. The“TBV” (Total blood volume) in field 334 is dynamically calculated(non-editable), based on the Height, Weight, and Gender fields 332, 333.The Donor Blood type is also preferably pre-populated in field 335,either from database 142 or (if unknown for this donor) pre-populatedwith Unknown. This field is preferably editable via a selection: O+, O−,A+, A−, B+, B−, AB+, AB−, or Unknown.

The Hematocrit/Hemoglobin field 336 is labeled either Hematocrit asshown or Hemoglobin (not shown), based on the system setup that isdefined by the System Administrator. Data in this field is required, andmay be entered by the operator, or a default value may exist. If theAdministrator configures this field to use a default value, andhistorical data of the configured type is available for this donor, thefield is pre-populated with the historical data. The type of historicaldata used as the default may be configured by the Administrator to beone of the following types: Average of last three pre-procedure values;Last visit's pre-procedure value; No default value; Gender-based defaultvalue; or blood center chosen default value. The value written to thedatabase and displayed on the page indicates if the value is one of theconfigurable defaults above or if it is a measured value entered by theoperator.

The Platelet Pre-count field 337 is also entered here. Data in thisfield 337 is required, and may be entered by the operator, or a defaultvalue may exist preferably as defined by the Administrator. If theAdministrator configures this field to use a default value, andhistorical data of the configured type is available for this donor, thefield is pre-populated with the historical data. The type of historicaldata which may be used as the default may be configured by theAdministrator to be one of the following types: Average of last threepre-procedure values; Last visit's pre-procedure value; No defaultvalue; Gender or Center-wide default. The value written to the databaseand displayed on the page preferably indicates if the value is one ofthe configurable defaults above or if it is a measured value entered bythe operator.

In addition to the above, preferably required items, the operator mayenter the appropriate optional donor vitals (see generally fields 338);Temperature (an optional field in localized units: Fahrenheit orCentigrade); Blood pressure; and Pulse (optional fields).

When all required information (and any optional information the operatorchooses to enter) has been entered, the operator clicks the Next button322 to proceed to the next page 341 or 351 (FIG. 3D or 3E), or the Backbutton 323 to return to the previous page 321 (FIG. 3B). Note, if arequired field does not have an entered value, an attempted click of theNext button 322 will preferably present a prompt that a value must beentered in this field before the wizard can proceed to the next page.Note, if the operator enters a value in a field that is above or belowthe allowable limits for that field (hard limits), or a value that isunusually high or unusually low (soft limits), a message will preferablybe made to appear. If this is a soft limit, the message informs theoperator that the value is outside the limits and asks if the operatorwishes to proceed. The operator may click a Yes option to use the valueand proceed, or No to enter a new value. If this is a hard limit, theoperator may be required to enter a new value in order to proceed. Also,if the blood center uses a blood bank information system, a warningmessage will preferably be made to appear when the operator changes adonor demographic field on the Donor Information page 331 (FIG. 3C).This warning would indicate that the demographics data must be changedin the blood bank information system to be permanently saved.

In a simplified process (usually for operators with lowerqualifications, or wanting or needing fewer choices), after the operatorhas clicked the “Next” button 322 (FIG. 3C), the operator is thenpresented with the Target Procedure page 351 (FIG. 3E) of the wizard.Screen 341 (FIG. 3D) is skipped in this simplified procedure. Theoperator may then accept the recommended target procedure (shownhighlighted with a rightward-pointing arrow icon 355 in FIG. 3E). Notethat the target procedure is obtained by the system 140 running theapheresis time and/or product yield optimization routines such as arerun on the Trima collection systems 10 (and as described below, seedescription accompanying FIGS. 7-10) in the present system application,and that the parameters for the highlighted procedure are preferablyshown above the procedure list. The operator may then optionally clickthe Finish button 352 (FIG. 3E) to complete the “Prepare Procedure”apheresis procedure selection process.

Note, the running of the apheresis optimization routines by system 140preferably involves the use of data either from storage in the centralmemory 142 and/or as input into system 140 via input devices 149 at anystation 148 (as described hereinabove) preferably through use of thesub-procedures described herein (i.e., using the screens shown in FIGS.2A-2I and 3A-3C) and communicated through subsystem(s) 146 and thenmanipulated by the manipulation device 144. The manipulated data maythen result in optimized data which can then be interpreted by thesystem as representing a system preferred target procedure (orprocedures) such as is shown in FIG. 3E. Again, optimized data wouldprovide usually either the largest yield in a certain time, or theshortest time to reach a minimum yield (see FIGS. 7-10, below). Othermanipulations may provide for procedures which may not be either time oryield optimized, but which a blood center may find otherwise perhapsmore desirable, such as platelet (or other component) preferences nomatter what the optimization program(s) might suggest. Thus, the system140 and manipulation device 144 can manipulate the donor statistics(vitals, etc.) against a large plurality of procedure types and comparewith blood center prioritizations to obtain various sorts of procedurelists such as that shown in FIG. 3E. Preferably, the optimal procedure(optimized or merely manipulated according to system administratorpre-selections) may be returned with the rightward-pointing icon 355;however, preferably also other procedures will be listed also withvarious icon representations to signify prioritization. For example, asshown in FIG. 3E, numerous procedures are shown with a circle with adiagonal line which here preferably represents procedures which are notavailable due to physical (and/or safety) constraints such as the donornot meeting a minimum hematocrit or total blood volume preferredtherefor. Green circles, inter alia, can be used to signify less thanoptimal procedures, which would nevertheless be available for this donorto be subjected to. Question marks could be used to signify procedures,which could be available options if the parameters (e.g., time, labvalues, etc.) were to change (i.e., if more time were allowed for acollection).

Note several alternative actions may be presented. For example, in someinstances it may occur that more than one target procedure may beindicated, whereby the operator may then choose the preferred procedure.Or perhaps the donor may be disqualified such that no procedures appearavailable. The donor can be disqualified for the donation based on thedonor vitals or screening questions. In this situation, the operator maypress the Cancel button 326 on any page in the Prepare Procedure Wizardto discontinue the prepare procedure process. The operator may thenremove the donor from the Checked-in Donor Queue, as described in the“Prepare Procedure” sub-procedure above.

Otherwise, the donor may be unable to donate if the central system 140cannot determine a valid apheresis procedure to run for this donor. Ifthis is the case, the central system 140 preferably displays a dialogbox (not shown) explaining the reason a procedure cannot be determined.Based on the blood center's policy, the operator may ask the donor ifthe donor can stay longer. The operator may then extend the proceduretime, as described in the “Adjust Donation Time” alternativesub-procedure below.

As noted, the operator may adjust the donation time. If the donor canonly stay longer or perhaps only a certain limited amount of time, theoperator may change the default maximum procedure time by clicking theAdjust button 353 (FIG. 3E). The operator is presented with theProcedure Adjustments dialog box 361 (see FIG. 3F), in which theoperator may enter a new maximum procedure time. The operator may thenclick the OK button to return to the Target Procedure page 351 (FIG. 3E)of the wizard. If the maximum procedure time is changed, the TargetProcedure page is re-optimized and possibly recommends a differentprocedure. It is also possible that there are no procedures available asa result of the time change.

Similarly, the operator may adjust the tubing set type availability. Ifonly certain tubing sets are available, the operator may change thetubing set type availability by clicking the Adjust button 353. Theoperator again is presented with the Procedure Adjustments dialog box361, in which all three tubing set types (e.g. Grey, White, and Blackoptions for the Trima apheresis systems 10; other optional set typesand/or designations may be used for other blood processing systems 10,as desired) are checked by default. The operator may uncheck one or moretubing set types. The operator may then click the OK button to return tothe Target Procedure page 351 of the wizard. If the tubing set typeavailability is changed, the Target Procedure page is re-optimized andpossibly recommends a different procedure. It is also possible thatthere are no procedures available as a result of the tubing setavailability change.

Note, the operator may also select certain different procedures in theprocedure list shown in screen 351 (FIG. 3E). The operator may select aprocedure with an icon indicating that the procedure can be run for thisdonor (though perhaps not the optimal procedure according to the system140), or a procedure with an icon indicating that the procedure can berun for this donor, but only if the donor's actual hematocrit and/orplatelet pre-count change significantly from the values entered inscreen 331 (or the default values used in screen 331). In any event,preferably the operator cannot select a procedure with an iconindicating that the procedure cannot be run for this donor. Note thatwhen the operator selects a different procedure in the list, theparameters for the selected procedure are shown above the procedurelist. Note, the operator may also view any of the listed proceduredetails. To do so, the operator may double-click a listed procedure toview a Procedure Details dialog box (not shown), which may provide moredetailed information about the procedure. The operator may double-clickeither the currently selected procedure, or any other procedure in thelist. The operator may click an OK button to close the Procedure Detailsdialog box (not shown) and return to the Target Procedure page 351 ofthe wizard. If the operator double-clicked a procedure other than thecurrently selected procedure, the procedure that the operatordouble-clicked would now preferably be selected (e.g., highlighted) inthe Target Procedure page 351.

Note also that an operator may select different donation options,preferably after the step depicted by screen 331 (FIG. 3C), but prior tothe step depicted by screen 351 (FIG. 3E). Preferably, however, thisoption would be limited to higher security users preparing the donation.Then an additional page 341 (FIG. 3D) would appear, allowing finercontrol of the donation. This page 341 would be presented only toindividuals with the higher privilege level. The following two stepscould be added for this operator. The operator would choose the bloodproduct types eligible for this donation (e.g. platelets, RBC's orplasma). These choices would be used to disqualify one or more producttypes from being collected. By default, all product types are preferablyeligible for a donation. Thus, a check in the corresponding box in area342 of the “Select Products and Configuration” page 341 would indicatethat the product type may be collected. If the corresponding box isunchecked, any procedure that would collect this product type isdisqualified in the Target Procedure page 351 (FIG. 3E). The threechoices are platelets, plasma and red blood cells. Any combinationhereof may be checked. As shown in area 343, the operator may alsoselect alternative apheresis system configurations or product focuslists to utilize for this donor's donation. Note that these changeswould preferably only apply to this donation. For Focus Lists, theoperator may select a product focus list from this drop-down list. Thecenter-wide default focus list is preferably pre-populated in thisdrop-down list. All focus lists that have been defined by theAdministrator will then appear in this drop-down list. For MachineConfiguration, the operator may select an apheresis system machineconfiguration from this drop-down list. The center-wide default machineconfiguration is preferably pre-populated in this drop-down list. Allmachine configurations that have been defined by the Administrator willthen appear in this drop-down list.

At any point while using the Prepare Procedure Wizard, the operator mayclick the History button 329 (see FIG. 3C) to view the donor's record.When the operator clicks the History button 325, the Donor Entry/Editdialog box 221 (see FIGS. 2B-2I) appears, showing all information in thedonor record. To return to the Prepare Procedure Wizard, the operatorclicks the OK button in the Donor Entry/Edit dialog box 221.

Note, the sub-procedure depicted by the screens in FIGS. 3B-3E may beknown generally as “screening” in suggesting that these functions may beperformed in the second room, the “Screening” room, of the three roommodel described above.

Then, in the next procedural step as shown by the display screen 401 inFIG. 4A, the donor may be assigned to a blood processing machine 10.Screen 401 may be accessed via a button such as the “Finish” button 352appearing on the last page 351 (FIG. 3E) of the “Prepare Procedure”wizard/sub-procedure, or more preferably by clicking the “assignmachine” icon 209 appearing in the icon work area 205 (see FIGS. 2A and4A, e.g.). Assigning a donor to a machine may be a simple matter ofclicking and dragging the donor's icon 402 (with or without photo) to anavailable Trima or like apheresis machine icon 404 as shown in therespective left and right portions 406, 408 of the main work area 202 inscreen 401.

Note however, that any particular donor will preferably not be available(i.e., no icon will preferably show up) in the icon list 406 (alsolabeled as a “Donor Assignment Queue”) until completion of the “PrepareProcedure” sub-procedure (i.e., as accessed using the “PrepareProcedure” icon 208, e.g.) as described for the wizard module in FIGS.3B-3F. However, after the “Prepare Procedure” sub-procedure iscompleted, preferably after the clicking of the “Finish” button 352 onthe last screen 351 of the wizard (see FIG. 3E), a donor icon for thatdonor, such as icon 402, e.g. is preferably automatically generated andautomatically placed in the icon list 406. Thus, the donor, asrepresented by the icon, is then ready to be assigned to a particularapheresis assembly 10.

In more detail, to do so, the operator will first preferablydouble-click the Assign Machine task icon 209 in the main window taskbar 205, or, alternatively, the operator may select the Assign Machineelement (not shown) from the Tasks menu 216. The Assign Machine taskwindow 401 is then displayed, showing two panes: the Donor AssignmentQueue 406 and the Machines list 408. The Donor Assignment Queue 406shows donor icons (e.g., icon 402) for all donors who are ready formachine assignment. Donor icons are preferably ordered in the queuebased on the time an operator finished using the Prepare ProcedureWizard (see above) to prepare a procedure for the donor. The donor forwhom the Prepare Procedure Wizard was finished the longest agopreferably appears at the top of the queue. The donor for whom thePrepare Procedure Wizard was finished most recently preferably appearsat the bottom of the queue. The Machines list 408 shows an icon for eachapheresis system in the facility that is enabled in the current network.To help the operator make a decision about which machine to select for adonor, the following information is preferably displayed as part of eachmachine icon: run status; time remaining if a procedure is currentlyrunning on the machine; name of the next donor queued for the machine;machine communications status (online or offline).

To assign a donor to a machine, the operator preferably selects a donoricon from the Donor Assignment Queue 406 and drags it to a machine iconin the Machines list 408. Alternatively, the operator may select a donoricon 402, e.g., (by highlighting/clicking it once, not shown) and amachine icon 404 and then click the Assign button 410 to make theassignment. A confirmation dialog box (not shown) may then be displayedwith “Yes” and “No” options to ask the operator to confirm theassignment. If the operator clicks the “Yes,” option, the system maythen close the confirmation dialog box, and, in the Assign Machine taskwindow 401, the following preferably occurs: the donor icon 402 isremoved from Donor Assignment Queue 406 and the machine information inthe Machines list 408 is updated to show that the donor is assigned tothe machine. If the operator clicks the option “No,” option, the systemcloses the confirmation dialog box, and, in the Assign Machine taskwindow 401, the following occurs: the donor icon 402 remains in theDonor Assignment Queue 406, and the machine information in the Machineslist 408 is unchanged. After a short delay, the donor information (andphoto, if available) appears on the apheresis system. In addition, thedonation-specific apheresis system configuration is in effect on themachine. At this point, the operator may continue using the AssignMachine task window or select another option in the system main window.

Some alternative process flows for donor/machine assignments are asfollows.

It may be possible that all machines 10 are non-functional. If this isthe case, the operator (or another member of the facility's staff) willneed to fix the problem at those machines 10, to make at least onemachine 10 available. If this is not possible, the operator may berequired to remove all donors from the Donor Assignment Queue, asdescribed below.

At any time prior to machine assignment, the operator may edit theinformation about a procedure by selecting the donor's icon (e.g., icon402) in the Donor Assignment Queue 406 in screen 401 and clicking theEdit button 405. The Prepare Procedure Wizard (see FIGS. 3B-3E) appears,allowing the operator to edit the procedure information. Once theoperator clicks Finish 352 on the last page 351 of the wizard, theAssign Machine task window 401 is redisplayed. (Alternatively, theoperator may redisplay the Assign Machine task window 401 by clickingCancel 326 on any page of the wizard; however, in this case, themodifications that were made in the wizard are discarded.)

At any time prior to machine assignment, the operator may remove a donorfrom the Donor Assignment Queue 406 by selecting the donor's icon (e.g.,icon 402) in the Donor Assignment Queue 406 and clicking the Removebutton 407. A Confirm Remove Donor dialog box (not shown) may be made toappear, allowing the operator to enter a reason for the removal and/orselect a reason from a predefined list (preferably created by theAdministrator). Once the operator clicks the OK option in the ConfirmRemove Donor dialog box (not shown), the donor's icon is removed fromthe Donor Assignment Queue 406.

The operator may also unassign a donor from an apheresis system 10 underthe following conditions; namely, if another donor is currently donatingon the machine, and the donor the operator wants to unassign is queuedto donate on the machine, and/or if the machine is offline. To unassignthe donor, the operator may click the machine icon 404 in the Machineslist 408 and then click the Unassign button 412. The machine icon 404returns to its previous state. In addition, an icon (e.g., icon 402) forthe unassigned donor reappears in the Donor Assignment Queue 406. Todistinguish this donor from donors who have not yet been assigned to anyapheresis system 10, this donor's icon is gray. The donor may then bereassigned to an apheresis system 10 as described in the basicprocedural flow, or removed from the Donor Assignment Queue 406 asdescribed in the “Remove Donor” alternative flow, above. Note: theUnassign button 412 is disabled when no machine icon is selected. If theoperator then clicks a machine icon (such as icon 402, inter alia) theUnassign button 412 will remain disabled, the unassign feature not beingavailable for that machine at this time.

If a donor is assigned to an apheresis system 10, but then is dismissedat the apheresis machine 10 using, for example, the touch-screen display199, the machine icon 402 in the Machines list 408 in the Assign Machinetask window 401 returns to the “Ready for Donor” state. In addition, anicon (e.g., icon 402) for the dismissed donor reappears in the DonorAssignment Queue. To distinguish this donor from donors who have not yetbeen assigned to any apheresis system 10, this donor's icon is“grayed-out”. The donor may then be reassigned to an apheresis system 10as described in the general sub-procedure for Assign a Donor, or removedfrom the Donor Assignment Queue 406 as described in the “Remove Donor”alternative sub-procedure, above.

After assigning a donor to an apheresis machine 10 as described, thedisplay screen 421 shown in FIG. 4B appears on the corresponding displayarea (e.g., touchscreen 199, if used) of the assigned blood componentapheresis assembly 10 itself. The operator may then either confirm theinformation appearing on the apheresis screen 421 by depressing the“continue” button 422, or the like; or the operator may touch/push thebox 423 marked with an “X” to decline the donor assignment, thus sendingthe donor data back to the central system 140 and figuratively send thedonor back to the “waiting/screening” room. The apheresis screen 421shown here may have touch-screen capabilities as understood in the art,or may accept input through other means such as mouse driven cursors,inter alia, which are within the skill of the art.

Note, it is still also conceived that though perhaps not preferable,there may be situations in which the system may be configured to allowthe operator to enter data directly on the apheresis machine 10 itselfand then perform data manipulation and/or optimization as is known formany existing machines 10 without requiring the use of a centralcomputer/database system 140. Nevertheless, it is also conceivable thatin such a situation it may be preferable to still collect data at acentralized system 140 for database or reporting purposes.

After the download of the information from the computer/database system140 to the actual apheresis machine assembly 10 as described, then thecomputer/database system 140 may preferably only be used for monitoringand/or reporting. This follows a preference that all actual apheresiscontrol during a procedure remains resident in the apheresis machine 10,itself. It is possible, however, if not preferable, to havecomputer/database system 140 exert control over apheresis machinefunctions, including process control manipulation and optimization,during procedures, as well. In either case, as shown in screen 501 ofFIG. 5A, it is at this point that the computer/database system 140 canbe used to monitor the procedure(s) occurring on one or more apheresismachines 10. All procedure interventions again would preferably occurdirectly on the apheresis machine 10 through its touch screen 199 orother input mechanism as known in the art.

In monitoring mode, real time monitoring of procedures on thecentralized computer/database system 140 allows the administrator toknow the status of collection of any or all machines 10 at a glance.This can help with scheduling and management. Alarm states may also bedisplayed and/or all other occurrences and/or activities of each machinemay be recorded (not specifically shown). As shown in screen 521, FIG.5B, detailed data information can be called up to assess the status of aprocedure. More details concerning these display screens and theinformation thereof will now be set forth.

In operation the operator preferably double-clicks the Monitor Proceduretask icon 210 in the main window task bar 205 (FIGS. 2A and 5A), or,alternatively, the operator may select the “Monitor Procedure” element(not shown) from the Tasks menu 216.

The present system 140 preferably provides users with the ability toview the status of all procedures currently running on machines 10connected on the local machine network 146A (see FIG. 1C), as well asprocedures which have completed on a machine 10, but for which not allrequired finalization data has been added to the procedure record.Status information is supplied continuously from each machine 10 tovisit status table (not shown) in the central database 142. The MonitorProcedure module scans an internal visit status table recurrently; theMonitor Procedure task window 501 is preferably updated based on thecurrent data in the internal visit status table. Using the MonitorProcedure function, operators can enter a comment about a procedure;enter finalization data about the procedure, such as supplies data andoperator roles; view more detailed information about a procedure'sstatus; or force record completion, inter alia.

The basic flow for the monitoring sub-procedure is as follows. Twodifferent general types of procedures are displayed in the MonitorProcedure task window 501; namely Active and Pending procedures. InActive procedures, all of the procedures currently running on machines10 connected to the machine network 146A, including active procedurescurrently in an alarm state, are shown. Pending procedures areprocedures that have been completed on the apheresis machine 10, but forwhich not all required finalization data may have been entered in theprocedure record. Note, procedures are considered active from the timethat donor and procedure data is downloaded from central system 140 toan apheresis machine 10, until the time that the central system 140receives indication from the apheresis machine 10 that either theprocedure run has been completed, or the operator has indicated on theapheresis machine 10 that the procedure run is incomplete.

In the Monitor Procedure task window 501, procedures are preferablydisplayed in table format (as shown in FIG. 5A). For each procedure, thefollowing information is preferably displayed: machine ID; collectionstage and status; donor name; procedure name; and the time remaining. Inaddition, an icon (e.g., icon 503) next to each procedure descriptionmay preferably indicate if the procedure is in an active, pending, oreven an alarm state.

The operator may then optionally select a procedure in the list and thenclick the Add Comment button 505 to enter a comment in the procedurerecord for that procedure. An Enter Procedure Comment dialog box (notshown), may then be made to appear. The operator can then select acomment from the pre-configured comment list (preferably created by theSystem Administrator) and/or enter a free-form text comment entry.

The operator may then optionally select a procedure in the list and thenclick the Procedure Information button 507 to enter data about theprocedure, such as supplies data and operator roles. A “FinalizeProcedure Information” dialog box may then appear, showing the Suppliestab. (For more information about this dialog box (not shown), see the“Finalize Procedure” descriptions (FIGS. 6C-6I, below).

The operator may also optionally select a procedure in the list and thenclick the Status button 509 to view more detailed information about theprocedure. A Procedure Status dialog box 521 (see FIG. 5B) may thenappear. (Optionally, the operator may double-click the selectedprocedure in the list to view this Procedure Status dialog box 521.)This dialog box 521 preferably shows the procedure time (time remaining,total time, and estimated end time) and the current collection statusfor each of the three blood product types (platelets, plasma, and RBCs),which may be in the process of being collected as part of a procedure.

Several alternative conditions and/or sub-procedures may be available inProcedure monitoring. For example, when an alarm, warning or alertcondition occurs within an active separation and collection procedure,the system may change the icon next to the procedure description in theMonitor Procedure task window 501 to an “alarm” icon (not shown). Theoperator can view the alarm description (preferably uploadedautomatically to central system 140 from the apheresis system 10generated by the run data for the procedure) by selecting the procedurefrom the procedure list in the Monitor Procedure task window 501procedures list 504, clicking the Procedure Information button 507, andthen clicking a Procedure Log tab in the Finalize Procedure Informationdialog box (see similar description in FIGS. 6C-6I, below). However, thealarm cannot be resolved in the preferred embodiment directly within thecentral system 140. The alarm must then be resolved at the machine 10.Once this alarm (and any other alarms on the machine) have been resolvedat the machine 10, the central system 140 may change the icon next tothe corresponding procedure description back to an “active procedure”icon such as icon 502, for example, as opposed to an inactive icon 503.

At any time, a procedure may no longer meet the active or pendingcriteria. An update to the visit status table in the central database142 may cause a procedure that was previously displayed in the MonitorProcedure list on screen 501 of procedures to be removed from the list.Only procedures that have a status of active or pending are preferablydisplayed in the procedure list. If a procedure previously was active orpending, but no longer meets that criteria the next time central system140 scans the visit status table, the procedure is no longer displayedin the Monitor Procedure task window 501.

At any point in monitoring procedures using screen 501, an operator maysort procedures in procedure list. In particular, the operator may clickone of the column headings in the procedure list to sort the proceduresusing different criteria. Procedures may preferably be sorted by one ofthe following: Machine ID, Status, Donor Name (first name, last name),Procedure, or Time Remaining. The first time the column heading isclicked, the procedures are sorted in ascending alphanumeric order. Eachsubsequent click of the column heading results in a display of theelements in the opposite alphanumeric order (ascending or descending).

As a usual last step in the overall blood component separation andcollection process using a central system 140, the record finalizationand reporting function of the computer/database system 140 will now bebriefly introduced. First, the computer/database system 140 ispreferably capable of capturing a great deal of optional informationfrom the apheresis system 10 as well as from manual entry. Thisend-of-run information may then be used in generating a multitude ofoptional reports in addition to standard run records, both of whichoptionally being formattable as desired by the operator (see FIGS. 6K,6L and 6M, described below). Further, various types of data can besorted and measured relative to each other as desired as well. Forexample, the time period of the entire collection procedure can bereported relative to the numbers and/or quantities of the productscollected (volumes or contents). Or, certain quality measures may bereported against either or any of the other data collected by thecomputer/database system 140. In addition, certain data may bemanipulated, edited or amended, or comments added thereto after acollection procedure. For example, certain additional information may beadded such as information about the type of tubing set used or postprocedure laboratory values. Nevertheless, the data generated by theapheresis machine 10, itself, very preferably would not be capable ofbeing edited or changed in any way. As above, more details of theoverall reporting functionalities will now be set forth.

The present invention allows operators to search for and select anyprocedure record in the central database 142, whether the procedurerecord is opened (as for active and pending procedures) or closed (asfor finalized procedures). As shown, for example by screen 601 in FIG.6A, operators can search for procedure records based on donor ID, unitnumber, or a range of dates. Once the desired procedure record has beenfound, the operator can access the procedure record to do one of thefollowing: View and/or enter finalization data (see the “FinalizeProcedure Record” sub-procedure described below); or, View and/or enterlab results data (see the “Lab Results Entry/Edit” description below;FIG. 6J)

The Basic Flow of this sub-procedure case follows the scenario that theoperator preferably searches by either donor ID or unit number, and thatthe operator wants to view/enter finalization data for the procedure.The operator preferably double-clicks the Select Procedure task icon 211in the main task bar 205 (FIGS. 2A and 6A), or, alternatively, theoperator may select the “Select Procedure” element (not shown) from theTasks menu 216 (FIG. 2A). The operator may then search the centralprocedure record database 142 for the desired procedure records, eitherby donor ID (see field 602) or unit number (field 603). Searching by arange of dates (see fields 604) is another preferred alternative. Theoperator clicks the desired radio button, which clears any informationthat may be currently shown in other selection option fields, and theoperator then enters a full or partial entry of the donor ID or unitnumber or dates in the appropriate box. Logical and/or boolean-typesearches are also preferably available. Alternatively, the operator mayuse the bar code reader (not shown) to enter the donor ID or unitnumber. For date searching, the operator may enter a starting date inthe From box, and enter an ending date in the To box. Either date can betyped in the text box or selected using a pop-up calendar (see calendar611 in FIG. 6B).

The operator may then click the Search button 610 or press the Enter key(on the keyboard, if used). The central system 140 then searches thecentral database 142 and displays all possible matching procedurerecords in the Search Results box 612. The search finds both open andclosed procedure records. In date searching, the Search Results boxdisplays all procedures that were performed within the specified daterange.

The operator may then click the desired procedure record in the SearchResults box 612, and then click the Procedure Information button 614(shown grayed-out in FIGS. 6A and 6B, since a record is not yet selectedthere, i.e., is not yet highlighted. A Finalize Procedure Informationdialog box 621, which may also be known as a Procedure Data Entry Editbox 621 (see FIGS. 6C-6I) then appears (optional double-clicking of theprocedure entry in the Search Results box 612 may also display theFinalize Procedure Information dialog box 621), here showing a Suppliestab 631. (For more information about this dialog box, see the “FinalizeProcedure” sub-procedure described below.)

Note: alternative search steps may also be performed. For example, ifthe operator clicks the Search button 610 with no search criteria given,then the Search Results box 612 preferably displays all procedurerecords in the central database 142. Alternatively, the correctprocedure record may not be found, in which case the operator may thenperform a new search by entering new search criteria.

Also, the operator may sort procedure records in Search Result box 612by clicking one of the column headings in the Search Results box 612.This will sort the procedure records using different criteria. Procedurerecords may preferably be sorted by one of the following: Unit Number,Date, Donor ID, or Donor Name (first name, last name). The first timethe column heading is clicked, the procedure records are sorted inascending alphanumeric order. Each subsequent click of a column headingresults in presentation of the records in the opposite alphanumericorder (ascending or descending). The operator may also view a LabResults Entry/Edit Dialog box (see box 701; FIG. 6J) by clicking thedesired procedure record in the Search Results box 612, and thenclicking the Lab button 616 to view the Lab Results Entry/Edit dialogbox 701 (FIG. 6J).

The operator may preferably access the Finalize Procedure Informationdialog box 621 for a particular procedure using one of two methods, theMonitor Procedure sub-procedure described above (see FIGS. 5A-5B),and/or the Select Procedure sub-procedure (FIG. 6A). The operator canaccess the Finalize Procedure Information dialog box 621 via the SelectProcedure task window 601 (see FIGS. 6A and/or 6B), preferably if thefollowing is true; the procedure will be run, is currently running, orhas been run under control of the central system 140. Note that whileusing Select Procedure, the operator can preferably access the FinalizeProcedure Information dialog box 621 regardless of whether the procedurerecord is opened or closed (this is in contrast to Monitor Procedure;the procedure record must preferably be in open status in order toaccess it from the Monitor Procedure task window 501). In addition, oncethe procedure has been completed on the apheresis machine 10, theoperator may use the Select Procedure task window 601 to access a LabResults Entry/Edit dialog box 701 (FIG. 6J), allowing the operator toview/enter lab product results.

Moreover, the operator can preferably access the Finalize ProcedureInformation dialog box 621 any time after the Prepare Procedure Wizard(see description of FIGS. 3B-3F) has been completed for thedonor/procedure. Thus, the operator may enter procedure information suchas supplies and operator roles (see below) while the procedure is stillrunning. However, even if all required data has been entered and savedin the procedure record, the procedure record is not considered closeduntil after the apheresis machine run has been completed (i.e., thecentral system 140 has detected a reboot or similar such signal from theapheresis machine 10). In addition, in order to update the status of aprocedure record from open to closed, all required information must bepresent in the Finalize Procedure Information dialog box. Requiredinformation is preferably either or both dictated by the central system140 (unit number, machine ID, donor ID, date), and determined by theSystem Administrator during system setup (required supplies, operatorroles, etc.).

Once the central system 140 changes the status of a procedure recordfrom open to closed, the central system 140 preferably removes theprocedure from the Monitor Procedure list 504 (see FIG. 5A). After thispoint, the system 140 may require use of the Select Procedure taskwindow 601 to revisit the procedure record. Note: a procedure ispreferably also removed from the Monitor Procedure list 504 if a SystemAdministrator forces record completion using button 511 in FIG. 5A(i.e., when the System Administrator determines that a record cannot orwill not be closable in accordance with normal procedures as dictatedherein).

To finalize a procedure, the operator will preferably select a procedurelisted in either the Monitor Procedure window 501 (FIG. 5A) or theSelect Procedure task window 601 (FIG. 6A), and then open the FinalizeProcedure Information dialog box 621 (FIGS. 6C-6I). The procedure recordfor the selected procedure is then displayed in the Finalize ProcedureInformation dialog box 621, preferably in initial form with a Suppliestab 631 as shown in FIG. 6C by default.

In the top portion 629 of the Finalize Procedure Information dialog box621, the operator confirms all preferably required and pre-populatedprocedure information, as follows: Unit Number; Machine ID; ProcedureDate; Donor ID; Donor Name; and End Time. All of the above informationis preferably non-editable, and is preferably downloaded from thecentral database 142 and/or the apheresis system 10 run data for thisprocedure.

On the Supplies tab 631 (FIG. 6C), the operator may enter proceduresupplies data. The supplies data entries may include the following: an“X” box or column, and various columns which may include a Description,a Lot number, an Expiration date, and a Manufacturer column, inter alia.In the “X” box/column, preferably the left-most column in the grid, theAdministrator preferably defines which supplies entries are required,using an “X” in this cell for such required supply information. In theDescription field, which is preferably non-editable as defined by anAdministrator during setup, the Administrator preferably sets upsupplies data by providing supplies descriptions and defining eachsupply as an optional or required entry. Each supply description theAdministrator defines preferably appears in the Description column inthe grid. The Lot number is preferably required if any supplies entry isa required entry. This can be typed into the box, or alternatively, theoperator may use the barcode reader to enter this data automatically.The Expiration date is also preferably required if any supplies entry isa required entry. This also can be typed into the box, or alternatively,entered using a barcode reader to enter this data automatically.Similarly, the Manufacturer data is preferably required if any suppliesentry is a required entry. Preferably a drop-down list, editable byselection only is used for entry here. Alternatively, the operator mayuse the barcode reader to enter this data automatically.

The operator may then optionally click the Operators tab 641 (see FIG.6D) in the Procedure Data Entry/Edit screen 621 (also known as theFinalize Procedure Information screen 621; FIGS. 6C-6I) to access theoperator role data entry area. Here, the operator may preferably enterinformation about operator roles. Each operator role entry may includethe following: an “X” box or column; a Role column, and Operator ID andName columns. The “X” box or column is again preferably the left-mostcolumn in the grid, with the Administrator having pre-defined anoperator role entry as required such that an “X” appears in this cellfor that role. The Role column is preferably non-editable, defined bythe Administrator during system setup. The System Administratorpreferably sets up operator roles data by providing operator roledescriptions and defining each operator role as an optional or requiredentry. Each operator role description the Administrator defines appearsin the Role column in the grid. The Operator ID and Name columns arepreferably required if the operator role is a required entry. These maybe drop-down lists, editable by selection only. When the operatorselects an item in the Operator ID drop-down list, the correspondingOperator Name cell is preferably automatically populated with theoperator's first and last names. Alternatively, an operator name can betyped in the box, but it reverts to match the currently selectedoperator ID the next time the procedure record is displayed.

The operator may then optionally click the Donor Information tab 651 inscreen 621 (FIG. 6E) to view the donor information for this procedure.The donor information is preferably supplied from the central donordatabase 142 and/or the blood bank information system, as well asinformation entered during the Prepare Procedure Wizard for thisprocedure. Once the central system 140 creates a procedure record for aprocedure, the donor information becomes a part of the procedure record,providing a snapshot of this information on the date the procedure wasrun. This information is therefore preferably non-editable. The donorinformation preferably includes the following: Gender; Height; Weight;TBV (Total Blood Volume); Blood Type (if available); CMV and HLA status(if available); and Pre-procedure values for hematocrit and plateletcount. In addition to the above information, this tab 651 preferablyalso shows the post-procedure values for hematocrit and platelet count.This information is preferably provided from the apheresis system 10 rundata for this procedure and thus, like the other information in thistab, these values are preferably non-editable.

The operator may then also optionally click the Record Status tab 661 inscreen 621 (FIG. 6F) to view the current central system procedure recordstatus. The status options preferably update automatically during theprocedure run and procedure record entry. The options, which arepreferably non-editable within this module, may include the ProcedureRecord, the Machine Release, the Visit Status and the Reason. TheProcedure Record preferably remains Opened until all requiredinformation has been entered in the procedure record; at that point, thecentral system may update this option to Closed. A check box can be usedto indicate whether the machine has been released for the next donor.The Visit Status preferably shows the current status of the donor'svisit, for example. If the procedure is currently running, this boxshows the same status that is shown in the Monitor Procedure task window501 (FIG. 5A) for this procedure). The Reason field may preferably beused to indicate whether and/or if the donor was removed from the DonorAssignment Queue 406 in the Assign Machine task window 401 (FIG. 4A) forany reason (incomplete procedure, dismissed at the apheresis system 10,etc.); the reason being displayed in this box.

The operator may then optionally click the Procedure Log tab 671 (seeFIG. 6G) to view the procedure name and the procedure log (an event logof all machine alerts, alarms, warnings, and operator adjustmentsentered throughout the procedure). Procedure comments that have beenentered by a system operator may be intermixed (according to timestamp)with the other information in this scrollable region. This informationis preferably variable for active donations and remains at the finalstatus display for pending and finalized procedures. The information ispreferably non-editable and is preferably supplied by the apheresismachine 10 run data and by the operator entering procedure commentseither in this dialog box 671 or via the Monitor Procedure task window501 (FIG. 5A). The operator may optionally click the Comment button toenter a comment in the procedure record for that procedure. An EnterProcedure Comment dialog box (not shown) may be made to appear. Theoperator can select a comment from the pre-configured comment list(preferably created by the Administrator) and/or enter a free-form textcomment entry. If the operator clicks the OK option, the FinalizeProcedure Information dialog box 621, Procedure Log tab 671 isredisplayed, showing the date and time the comment was created, as wellas the user ID for the user who was logged on when the comment wascreated. If the operator clicks Cancel, the Finalize ProcedureInformation dialog box 621, Procedure Log tab 671 is redisplayed, butthe comment is not included in the procedure record.

The operator may then optionally click the Run Summary Tab 681 (FIG. 6H)to view the machine-estimated product volume information. Thisinformation is preferably provided by the apheresis machine 10 after therun is complete. Until the procedure is completed, all of the fields inthis tab are blank. The information would then be non-editable anddefaulted from the procedure run data (machine run summary). Thisinformation preferably includes the following: the estimated volume forplatelet, plasma and RBC products; the AC volume in platelet, plasma andRBC products; the estimated yield for platelet products; the total ACvolume used; the AC administered to the donor during the procedure; thetotal blood volume processed; and Summary remarks, preferably includingone or more of the following: a reminder to label LRS platelet productas having less than 1×10e6 white blood cells (if so leukoreduced, as onthe Trima system 10; a reminder to count the product; a reminder toverify platelet yield; a reminder to verify platelet volume; a reminderto determine whether platelet concentration is out of range; a reminderto verify plasma volume; and/or a reminder to verify RBC product.

The operator may then optionally click the Blood Loss Tab 691 (FIG. 61)to view blood loss entries. Blood loss information preferably includesthe Product, the Tubing Set Residual, the Blood Sample and an Othercolumn. A check box for Rinseback Completion is also provided. In moredetail, the Product column shows product volume for plasma and RBCs.This information is preferably downloaded from the apheresis system 10run data for this procedure, and is preferably non-editable. Theinformation is determined based on the procedure that was run and thedonor's hematocrit. Until the procedure is completed, these fields areblank. The Tubing Set Residual preferably shows the volume of plasma andRBCs remaining in the tubing set. This information is also preferablydownloaded from the apheresis system run data for this procedure, and ispreferably non-editable. During the procedure, this information isdetermined based on the collection status, the tubing set type, theprocedure that is being run, and the donor's hematocrit. When theprocedure is completed, this information is determined based on all ofthe above, as well as whether or not rinseback was completed for theprocedure. The Blood Sample column presents the volume of blood, enteredby operator for plasma and/or RBCs, according to the facility's SOPs.The default value if, used, is preferably specified by theAdministrator. The Other column includes any Other volume of blood (forexample, estimated volume of a spill), entered by operator for plasmaand/or RBCs, according to the facility's SOPs. The Donor CompletedRinseback check box is checked if rinseback was completed for theprocedure. Until the procedure is completed, this box remains unchecked.This information is also preferably downloaded from the apheresis systemrun data for this procedure, and is preferably non-editable.

After entering and/or confirming the above data (particularly as may berequired by the SOP's of a particular blood center), the operator maythen click the “OK” button 622 (FIGS. 6C-6I) to save the record. Thecentral system 140 saves the procedure record. If all the requiredinformation has been entered, the central system 140 updates the statusof the record to be closed. The central system 140 may then also closethe Finalize Procedure Information dialog box 621 and redisplay eitherthe Monitor Procedure task window 501 (FIG. 5A) or the Select Proceduretask window 601 (FIG. 6A), depending on the method the operatororiginally used to open the Finalize Procedure Information dialog box621.

Alternatively, the Operator may click the Apply button 624, at any pointwhile the Finalize Procedure Information dialog box 621 is displayed tosave the data in the procedure record up to that point, without closingthe dialog box 621. The central system 140 saves the procedure recordand, if all the required information has been entered, the system 140updates the record's status to closed. Similarly, at any point while theFinalize Procedure Information dialog box 621 is displayed, the operatormay click the Cancel button to cancel the current entry session. Thecentral system 140 may then discard all unsaved changes in the procedurerecord, and close the Finalize Procedure Information dialog box 621 andredisplay either the Monitor Procedure task window 501 or the SelectProcedure task window 601, depending on the method the operator used toopen the Finalize Procedure Information dialog box 621.

Various alternative actions are also available. For example, theOperator may view a record for a procedure that has not yet begun. Thecentral system 140 creates a procedure record as soon as the operatorcompletes the Prepare Procedure Wizard for a procedure (see FIGS.3B-3E). However, the procedure does not appear in the Monitor Proceduretask window until the donor and procedure information is downloaded tothe assigned apheresis system 10. Prior to that time, if the operatorwants to view the procedure record, he/she can search for the procedurerecord using the Select Procedure task window 601. The operator may alsoview and/or edit information in the Finalize Procedure Informationdialog box 621, as described here; i.e., at any point in the overallprocess, however, in most instances, doing so at before a process hasbegun or during the process would be premature.

However, Lab data entry/edit may also be performed from screen 601 (asintroduced above) at any time in the overall process; generally aftersuch data has been processed and returned from the Laboratory. Again,the Lab Data Entry/Edit screen 701 (FIG. 6J) is preferably accessed byselecting the Lab button 611 in screen 601 (FIG. 6A). Then, labinformation may be entered/edited in screen 701 according to the producttypes (see the three tabs for Platelet Products, Plasma Products and RedBlood Cell Products). Then, Lab data entry/editing may be performedaccording to the information on hand. For example, Collected Productinformation can be entered/edited (although this information may bedownloaded from the apheresis machine 10, and thus may be madenon-enterable/non-editable, here); Residual Count information can beedited/edited (as may be applicable); and Split Product information maybe entered/edited (Split ID numbers; concentrations, bag weights,volumes and/or yields, e.g.), here.

During use of the Select Procedure task window 601, the operator mayclick one of the column headings in a grid to sort the entries usingdifferent criteria. The first time the column heading is clicked, theentries are sorted in ascending alphanumeric order. Each subsequentclick of the column heading results in the opposite alphanumeric order(ascending or descending).

Note: the donor may be dismissed at the machine 10 after the centralsystem has initiated a record. In such a case, the central system 140preferably automatically closes the procedure record if both of thefollowing are true: The donor is assigned to an apheresis system, butthen is dismissed using the apheresis system touch-screen display 199before the procedure is begun; and, the operator does not assign thedonor to a different machine 10, but instead removes the donor from theDonor Assignment Queue 406 in the Assign Machine task window 401 (SeeFIG. 4A). For more information, see the following alternative actionsdescribed relative to the “Assign Machine” sub-procedure relative toFIGS. 4A and 4B.

The central system may also detect an Incomplete Run, in which case, thesystem 140 preferably automatically closes the procedure record if bothof the following are true: the donor is disconnected from the apheresissystem 10 and the operator indicates on the machine that the run isincomplete, and the operator has completed all information necessary tofinalize the procedure record. If the operator has not yet completed allinformation necessary to finalize the procedure record, the procedurerecord remains opened until such information has been entered, asdescribed, above.

Note, throughout the descriptions of preferred options above, there areset forth a plurality of described instances of data/informationpreferably being communicated to and from the central system 140 fromand to the apheresis system(s) 10. Nevertheless, it is understood thatnot all of these particular types of data or information may be used orcaptured or communicated by many available blood processing systems.Thus, it should be understood that all such instances in the abovedescription are intended as the preferred embodiment, and that lesserdirect communications and mere manual data transfer from and to acentral system 140 and associated blood processing systems 10 are alsointended within the scope of the present invention. Thus, for example,data may be manipulated and/or optimized on/in a central system 140, andthe results of which may not be readily transferred to a bloodprocessing system 10 (see perhaps systems 10B and/or 10C as shown inFIG. 1B, e.g.), and therefore the resulting manipulated and/or optimizeddata or information may have to be operator entered into such a system10 for use thereby. Similarly, the results of the processing/collectionprocedure performed by a lesser compatible system (see again, perhapssystems 10B and/or 10C, e.g.) may not be automatically communicated tothe central system 140, but may be operator transferred (i.e., manuallyentered) upon procedure completion. Instances of preferably non-editablefields or data, as set forth above, would thus not be applicable here.Rather, such data fields would indeed be editable/enterable dependingupon which type of blood processing system 10 was being used. A furthersimilar process for data handling may be performed for whole bloodcollection systems (see e.g., the whole blood representation 10D in FIG.1B), wherein a data-communicating machine is often not used (at leastnot in the initial collection process; a needle connected to areceptacle/bag by a tube may be the collection device 10D). However,data/information may still be captured by manual data entry throughoutthe process, for example, from initial Reception and Screening throughto Collection completion. Moreover, subsequent (or chair-side, orbed-side) processing may even be performed such as to separate thecollected whole blood into components, which may be desirably tracked ina central system 140. The data would rather only be manually entered, orperhaps even certain subsequent (or chair-side, or bed-side) processingmachines may have data communication abilities so as to communicate witha central system 140. The quantity and/or quality of data would thenonly differ as to the type of procedure performed (e.g., whole bloodseparated into which components).

Lastly, if the operator desires to view and/or print an End-of-Runreport when the procedure is complete, he/she may do so using theReports feature of the Everest software (see generally FIGS. 6K, 6L and6M, for example). Various pre-defined and/or system administratordefined reports can be generated about donors, procedures and collectedblood products, inter alia. The reports command may be an icon in theicon task bar 205 (though not shown as such here), or may be accessiblethrough the Tasks menu 216 (see FIG. 2A, e.g.), inter alia. A list ofpreviously configured reports may then be made to appear as for exampleis shown in dialog box 711 of FIG. 6K. Upon selection of a report fromthe list in box 711, a report generating dialog box such as box 721(FIG. 6L) may then be made to appear. After entry of the prompted-forinformation, a report may then be generated. An example report is shownin the report preview screen 731 (FIG. 6M). The presently preferredreport generator is based on the Oracle Reports platform, which is areadily available software application (from the Oracle Corporation,Redwood Shores, California). Thus, data from the central may betransferred to such a Report generating platform to create reports ofany desirable format in fashions known and understood by those skilledwith Oracle Reports or like software applications.

As mentioned throughout, an important element of the overall system 140is the communication subsystem 146, which provides communication betweenand/or among the various other devices/elements. As described above,subsystem 146 may involve hardwire or cable connections between thevarious elements; and/or it may involve other devices and/or software. Afurther communication alternative with the computer/database 140 maygenerally involve the internet. As is known in the art, the internetprovides a “common language” through which multiple different systemscan communicate without requiring special tailoring of each system. Forinstance, various protocols have been established to facilitate datacommunication on what has become known as the internet. In particular,the TCP-IP (Transmission Control Protocol—Internet Protocol) is aninternet protocol structure which was developed in a 1973 Department ofDefense research project designed to link a “network of lowest bidders”;now in wide commercial usage since about 1988. In particular, the TCPensures that the information goes to its destination correctly; verifiesthe correct delivery of data from client to server; and provides acommon way of sharing information among different types of systems (PC,MAC, SUN workstation, etc.). Further, the IP also ensures theinformation goes to the right location; moves packets of informationfrom node to node; and provides unique IP addresses assigned by InterNIC(NSF, AT&T, & Network Solutions, inter alia.). The Internet thenprovides a web of information, which can be accessed through a singleinterface (web browser). The internet can also provide a communicationmedium between a computer/database system 140 and various other computerinformation systems such as those shown in FIG. 1B; and ostensiblyprovide communication protocols to or with the apheresis machines 10 aswell.

As an example, as inventory is withdrawn or replenished within thehospital or blood bank, this information can be recorded via bar code.By connecting the information to the hospital information system (HIS)and on through to www.bloodaccess.com, or a like internet connectionaddress, a blood donation center can then access and monitor localinventory levels. When one hospital needs a stat or immediate order fora given blood component, the blood center may then locate and arrangetransfer of the units from one center or one hospital to another. Theblood center can then replenish the units taken from the hospital withina short period of time (such as 24 hours) using flexible collectionthrough automation. Moreover, this is not merely an inventory tool, itmay also be tailored to fill specific needs such as in the “dosing”model introduced herein.

Similarly also, donor recruitment and/or eligibility and/orqualification can be run by a centralized system to determine whichdonors may be able to provide certain products at a certain time. Thedata may be obtained by data input as above, or with data alreadyexisting in the memory 142 and/or as may be obtained by communicationwith a discrete information system. Most preferably, these procedurescould be performed without the specific potential donor present topredict what the donor could yield, and then if a desirable product ispredicted (i.e., the potential donor is eligible or qualified to givethe desired product(s)), the potential donor could then be contacted torecruit them to undergo the procedure. In this fashion, a blood centercould better tailor its blood and blood component supply to better matchdemand.

By way of background and provision of a detailed application of thepresent invention, a description of the blood apheresis process andassociated machinery will now be set forth. Various embodiments of bloodcomponent collection assemblies may incorporate principles of thepresent invention. However, as noted above on-line techniques have beendetermined to be quite effective and thus the present invention is beingdescribed with reference to such techniques. One embodiment of anon-line technique and attendant apparatus which may be incorporated intothe blood component collection system 2 of FIG. 1A is illustrated inFIG. 7A. An on-line technique herein refers to the use of a bloodprocessing device which is controlled by parameters entered directlytherein and calculated or manipulated thereby to achieve all necessarycontrol parameters. Off-line techniques refer to the use of data entryand/or data manipulation performed by devices not resident on or withinthe particular blood processing device; though which are preferablydisposed in data communication therewith.

The blood component collection assembly 10′ of FIG. 7A utilizes anon-line technique in that a donor 14 (e.g., the whole blood source) isdirectly integrated with the system 10′ by fluid interconnection withthe blood component collection device 18. This particular on-linetechnique is more particularly referred to as a dual needleconfiguration since there are two fluid interconnections between thedonor 14 and the blood component collection device 18.

The donor 14 is fluidly connected to the blood component collectiondevice 18 by an inlet line 22 and appropriate needle assembly (notshown). Whole blood from the donor 14 is thus continuously provided tothe blood component collection device 18 through the inlet line 22 forseparation of the desired blood component(s) therefrom, utilizing aninlet pump 26 (e.g., a peristaltic pump) to maintain this flow ifdesired/required. Prior to the blood of the donor 14 entering the bloodcomponent collection device 18, anticoagulant from an anticoagulant(“AC”) container 30 may be provided to the whole blood, utilizing an ACpump 32 (e.g., a peristaltic pump) to maintain this particular flow ifdesired/required. Consequently, the inlet flow to the blood componentcollection device 18 typically includes both a flow of whole blood fromthe donor 14 and a flow of anticoagulant from the AC container 30.

The blood component collection device 18 separates the whole bloodprovided on-line by the donor 14 into three primary constituents, namelyplatelets, a combination of red and white blood cells (“RBC/WBC”), andplasma. The platelets collected from the blood component device 18 aredirected through a platelet collect line(s) 34 to one or more plateletcollect bags 38 via a collect pump 36. The plasma and RBC/WBC areprovided back to the donor 14 through a plasma line 42 and RBC/WBC line46, respectively, both of which are interconnected with a second needleassembly (not shown) on the donor 14 via a donor return line 50. Theplasma line 42 includes a plasma pump 40 (e.g., a peristaltic pump) tomaintain the flow of plasma if desired/required. Although plasma may beprovided back to the donor 14 in the above manner, it may be desirableto collect the separated plasma in some cases. In this regard, a plasmacollect bag 54 may be provided and interconnected with the plasma line42 (interconnection shown in phantom). In this case, appropriate valving56 may be incorporated in the plasma line 42.

The blood component separation assembly 10″ of FIG. 7B is similar tothat of the dual needle configuration of FIG. 7A except that a singleneedle assembly (not shown) integrates the donor 14 within the bloodcomponent collection assembly 10″. Consequently, similar components aresimilarly identified where appropriate. With regard to the single needleconfiguration of FIG. 7B, whole blood of the donor 14 initially flowsthrough a donor access line 62 and into an inlet line 66 which isfluidly connected with the blood component collection device 18 suchthat the platelets are separated and collected in the above-describedmanner. The plasma and RBC from the blood component collection device 18flow through the plasma and RBC/WBC lines 42, 46, respectively, both ofwhich are fluidly interconnected with a return flow controller 74. Asabove, however, the plasma may alternatively be directed to a plasmacollect bag 54. In the event that plasma is not collected, the RBC/WBCand plasma are provided back to the donor 14 through the return flowcontroller 74 via a donor return line 70, which is interconnected withthe donor access line 62. As can be appreciated, since only a singleline is directly connected to the donor 14, namely the donor access line62, blood is either being removed from or provided back to the donor 14such that the procedure is effectively two-step versus continuous inrelation to the donor 14.

An exemplary blood component collection device 18 which may be used inthe blood component collection assembly 10 is more particularlyillustrated in FIGS. 8A-8B. This and like devices 18 are the subject ofvarious U.S. Patents, see particularly No. 4,387,848 to Kellogg et al.,entitled Centrifuge Assembly, issued Jun. 14, 1983, and U.S. Pat. No.4,708,712 to Mulzet, entitled Continuous-loop Centrifugal Separator,issued Nov. 24, 1987; inter alia, the disclosures of which areincorporated by reference in entireties herein. Such devices 18 are alsocommercially available from the assignee of the present application assuch may be incorporated in the COBE Spectra and/or Trima apheresissystems.

Referring to FIGS. 8A-8B, the blood component collection device 18utilizes a processing channel 80 to provide the desired disposableextracorporeal circuit. The channel 80 is positioned preferably within agroove formed directly or indirectly in a centrifuge rotor (not shown)(e.g., a separate filler may receive the channel 80 and be attached tothe centrifuge rotor), and is illustrated in the two-stage shape, whichit assumes during processing (i.e., during flow of blood therethrough).Although a two-stage channel 80 is shown and described further herein,the present invention is not so limited; rather, the present inventionmay be used also with single-stage and/or any other centrifugalconfiguration as well as with non-centrifugal separation machines ordevices.

As shown and described herein, the two-stage processing channel 80generally includes a first stage 84 for collectively separating redblood cells (“RBC”) and white blood cells (“WBC”) from platelet-richplasma, a second stage 92 for thereafter separating platelets from theplatelet-rich plasma, a transition portion 88 defining a separationbetween the first stage 84 and second stage 92, and a control chamber124 for maintaining a proper interface between the first stage 84 andsecond stage 92, namely the position of the interface between theRBC/WBC and platelet-rich plasma within the transition portion 88.

The first stage 84 extends from one end of the control chamber 124 alongan arcuate path generally inwardly, toward the axis 132 about which theprocessing channel 80 rotates via the centrifuge rotor, untilterminating at the transition portion 88. Specifically, the end of thefirst stage 84 adjacent the control chamber 124 is positioned at agreater radial distance from the axis 132 than the end of the firststage 84 adjacent the transition portion 88. An inlet tube 96 is fluidlyconnected with the first stage 84 between its two ends to introducewhole blood into the processing channel 80 and a RBC/WBC tube 100 isprovided in the control chamber 124 for removing the separated RBC/WBCfrom the channel 80. Both the inlet tube 96 and RBC/WBC tube 100 extendexternally of the rotatable device 18 for interconnection with the donor14 and/or collection bags 38, 54.

As RBC/WBC sediment against the outer wall in the first stage 84 duringrotation of the centrifuge rotor they are directed and counterflowtoward the RBC/WBC tube 100 for removal from the channel 80 due to theincreased centrifugal forces at the RBC/WBC tube 100 in comparison withthe transition portion 88. That is, since the first stage 84 extendsalong an arcuate path generally outwardly away from the axis 132proceeding from the transition portion 88 to the control chamber 124,the centrifugal force differential along the first stage 84 establishesthe described counterflow of the separated RBC/WBC. Moreover, thetransition portion 88 also assists in providing for this counterflowsince it extends along an arcuate path generally inwardly toward theaxis 132 proceeding from the first stage 84 to the second stage 92.

The platelet-rich plasma, which has a lower density than the RBC andWBC, flows beyond the transition portion 88 from the first stage 84 intothe second stage 92 for further processing, while the RBC/WBC aredirected back toward the RBC/WBC tube 100 in the above-described manner.The second stage 92 initiates at the radially inwardmost part of thetransition portion 88 and extends along an arcuate path generallyoutwardly away from the axis 132 to a platelet collection chamber 104.Platelets are removed from the processing channel 80 at the plateletcollection chamber 104 by a platelet tube 108 which interfaces with theouter wall of the processing channel 80 at the platelet collectionchamber 104. Thereafter, the second stage 92 extends along an arcuatepath generally inwardly toward the axis 132 until terminating at theplasma tube 112. Both the platelet tube 108 and plasma tube 112 extendexternally of the rotatable device 18 for interconnection with theplatelet collect bag(s) 38 and donor 14/plasma collect bag(s) 54,respectively.

Platelets which do not separate from the plasma in the initial portionof the second stage 92 between the transition portion 88 and plateletcollection chamber 104 are separated in the portion of the second stage92 between the platelet collection chamber 104 and the plasma tube 112.These platelets will flow back towards the platelet collection chamber104 in the opposite direction of the flow of platelet-richplasma/platelet-poor plasma through the second stage 92 due to theconfiguration of this portion of the second stage 92. That is, theplatelet collection chamber 104 assumes the radially outwardmostposition in the second stage 92 such that all platelets, regardless ofwhere separation occurs in the second stage 92, flow towards theplatelet collection chamber 104 for removal from the channel 80.

Platelet-poor plasma exits the second stage 92 and flows out through theplasma tube 112, which interfaces with the inner wall of the processingchannel 80 and/or continues to flow through the remaining portion of theprocessing channel 80 to the control chamber 124. Plasma which flows tothe control chamber 124 exits the channel through the control tube 114,which joins with the RBC/WBC tube 100 into a single outlet tube 120. Thepositions and diameters of the RBC/WBC tube 100 and control tube 114 andthe joinder of such into the common outlet tube 120 regulate theposition of the RBC/WBC-platelet-rich plasma interface within thetransition portion 88 using conservation of mass principles.

As noted above, each blood component collection device 18 may include aprediction model appropriately interfaced with the operator input module16 and/or disposed on or within the manipulation device 144 or in anassociated memory device 142 as shown in FIGS. 1A-1D any and/or all ofwhich may be used to configure the prediction model and/or to allowoperator input of various parameters to be used by the prediction modelfor predicting a yield of a particular blood component to be collectedbefore a collection procedure is initiated using a compilation ofalgorithms. The preferred prediction model and the optimizationalgorithms which are associated with the present invention are describedin detail in U.S. Pat. Nos. 5,496,265; 5,658,240; 5,712,798; and5,970,423; inter alia, all of which being commonly assigned to theassignee of the present invention, the disclosures of which beingincorporated herein in their entireties as if fully set forth here bythis reference thereto. The algorithms and disclosures thereof will thusbe only briefly described herein.

The prediction model is typically configured by the site (e.g., theblood bank/center) for a particular blood processing or componentcollection procedure (e.g., single or dual needle) used by the site.Both single-needle and double needle procedures as shown in FIGS. 7A and7B will be used in the following general description, particularly inrelation to a platelet-collecting procedure (although of course, anycollection procedure can be understood as being substitutable herein).In this regard, an AC infusion rate (i.e., the rate at whichanticoagulant is provided to the donor 14 per the blood volume of thedonor 14) and the AC ratio (i.e., the collective flow of AC and bloodthrough the inlet line 22 in relation to the flow of AC through the line22) must be specified (through configuration or modified input as willbe discussed below). Moreover, in the event that plasma is to becollected into the plasma collect bag 54 in the collection procedure,the maximum amount of plasma which should be collected considering themedical and physical characteristics of the donor 14 must also beprovided.

And, as described in the above-mentioned patents, there are twoalternatives for establishing the plasma volume limit. These will nottherefore be described further here.

Further information is required by the prediction model prior toperforming its yield prediction function. For instance, the totalprocedure time is typically input by the operator or pre-configured bythe site (e.g., the blood bank/center). Moreover, the total proceduretime may be affected by whether a stepdown option is utilized for theblood component collection device 18 so as to enhance separation of thevarious blood components. When this stepdown option is selected, theangular velocity of the blood component collection device 18 isincrementally reduced during the platelet-collection procedure. Forinstance, the stepdown option could provide for angular velocities forthe device 18 of 2400, 2200, and 2000 RPM, each of which would be for aspecified duration.

Based upon the foregoing, the configuration of the prediction model inrelation to the blood component separation assembly 110′ and associatedprotocol in effect standardizes site protocol for purposes of “normal”operations. However, for a particular donor 14 it may be desirable toalter the “configuration” for one processing run. Consequently, theprediction model may utilize a procedure in which certain parametersutilized in the following equations may be adjusted on a one-at-a-timebasis. Such is referred to as modified input data and the associatedparameters are procedure time, inlet flow rate to the device 18, ACratio option, the desired platelet collect volume, the desired plateletcollect concentration, and the desired source plasma volume to becollected. Moreover, other parameters such as AC infusion rate, stepdownoption (yes or no), needle option (single or double), and high flowoption (yes or no) may also be entered as modified input data by anoperator.

Having configured the prediction model in the above-described manner,the following additional information is provided and is utilized in thevarious calculations of exemplary Equations 1-22 presented below: (1)needle option, namely whether the procedure is dual needle (FIG. 7A) orsingle needle (FIG. 7B); (2) run identification number for purposes ofassociating the data/output generated by the various equations with aparticular donor 14 and processing run; (3) the gender of the donor 14;(4) the height of the donor 14; (5) the weight of the donor 14; (6) thetotal blood volume as calculated in Eq. 10 below; (7) the hematocrit ofthe donor 14, either based upon an initial estimation and thereafterupdated based upon analysis of the donor's 14 blood sample (e.g., by acell counter) or input directly from such an analysis; (8) the plateletpre-count, either based upon an initial estimation and thereafterupdated based upon analysis of the donor's 14 blood sample (e.g., cellcounter) or input directly from such an analysis; and (9) whether plasmacollection is desired in conjunction with the platelet collection.

Based upon the above initial configuration and subsequent data input(except when entered as modified input data), the following output isgenerated by the prediction model: (1) platelet yield; (2) inlet flowrate; (3) AC ratio; (4) procedure time; (5) platelet collect volume; (6)platelet collect concentration; (7) source plasma volume; (8) AC in theplatelet and plasma collect bags 38, 54; (9) platelet post-count; (10)AC infusion rate; and (11) output approval. This information is utilizedat least in part in the following equations to generate, inter alia, thepredicted platelet yield value of the collected platelets for the caseof the dual needle procedure of FIG. 7A and also for the case of thesingle needle procedure of FIG. 7B. The differences between thoseprocedures with regard to the prediction model are identified herein. Aswill be appreciated, some of the equations are utilized in thecalculation of the predicted platelet yield, whereas other equations areused to generate additional information for output and informationalpurposes. The variables or parameters and the units associated therewithof the equations are presented after the equations in the VariablesIndex.

Platelet Yield:Y=1×10⁶ C _(PR) V _(B) F _(Y)[1−exp[−E _(C)(f _(BP)−0.12)]]  (Eq. 1)F _(BP)=(Q _(IN) t _(E)+50)(1−1/R)/V _(B)  (Eq. 2)and where:Q _(IN) =RQ _(AC)=0.001IV _(B) PR≦150  (Eq. 3)

Alternatively, the platelet yield may be expressed as:Y=1×10⁶ C _(PR) V _(B) F _(Y)[1−exp[−E _(C)(0.001I(R−1)Pt_(E)+50(1−1/R)/V _(B)−012]]≧0  (Eq. 4)

Platelet Collection Efficiency:E _(c) =C ₁ −C ₂ exp[9.91(1−1/R)H]Q _(INA)≧0  (Eq. 5)where the constant C₁ is defined as follows:C₁=0.803—dual needle, without stepdownC₁=0.840—dual needle, with stepdownwhere the constant C₂ is defined as follows:C₂=4.08×10⁻⁵—dual needle, without stepdownC₂=8.54×10⁻⁵—dual needle, with stepdownand where:Q _(INA) =Q _(IN)(t _(E) /t _(P))  (Eq. 6)

In Eq. 6, t_(p) may be provided as configuration data or modified dataas provided above, or alternatively may be derived from the solution ofEq. 4 for t_(E).

Effective Procedure Time:t _(E) =t _(P) , Q _(IN)≦45t _(E) =t _(p)−50(1/45−1/Q _(IN)), Q _(IN)>45  (Eq. 7)

Only high-flow protocol is used for Q_(IN)>45.

AC Infusion Rate Constant:I=1000Q _(IN)/(PRV _(B))  (Eq. 8)

Alternatively to the use of Eq. 8 for the derivation of the AC infusionrate constant I, such may be provided as configuration or modified inputdata pursuant to the above.

AC Ratio:

Initially, the AC ratio may be provided as configuration or modifiedinput data pursuant to the above. In configuration, it is defined asfollows:R=1+2.51/H lowR=1.33(1+2.51/H)mediumR=1.67(1+2.51/H)high  (Eq. 9)

Total Blood Volume:V _(B)=604+0.006012L ³+14.6W ml(male)  (Eq. 10)V _(B)=183+0.005835L ³+15.0 W ml(female)

Plasma Collect Factor:

AC infusion rate control maintains the AC flow to the donor as:Q _(ACD)=0.001 IV _(B)  (Eq. 11)where the inlet flow associated with this is:Q _(INO) =RQ _(ACD)=0.001 IRV _(B)  (Eq. 12)

Q_(IN) is proportional to the total AC flow, as given by Eq. 3, whichincludes the AC that flows to the platelet collect bag 38 and the plasmacollect bag 54. P (Eq. 13) is the factor by which QIN is increased bycollecting AC, relative to not collecting AC. That is,P=Q _(IN) /Q _(INO)=(average Q _(AC))/Q _(ACD)  (Eq. 13)where:P=1+(f _(ACD) /Q _(ACD))[V _(C)/(t _(P)−150/Q _(IN))+V _(SP)/(t_(P)−500/Q _(IN))]  (Eq. 14)and where:f _(ACP)=[(R−1)(1−H)]⁻¹  (Eq. 15)

Platelet Collect Volume:V _(C)=1×10⁻⁶ Y/[C _(B)(1+f _(ACP))]  (Eq. 16)

Source Plasma Volume:

The four choices are provided as follows:V _(SP)=0≧0V _(Sp) =V _(CON) −V _(C)≧0V _(SP) =F _(SPVB) −V _(C)≧0  (Eq. 17)V _(SP)=specified as modified input≧0

Where:V _(CON) =V _(CONL) , W<W _(C)  (Eq. 18)V _(CON) =V _(CONN) , W≧W _(C)

And where:0.01<f _(SP)≦0.15  (Eq. 19)

Donor Post-countC _(PO) =C _(PR) exp[−E _(C)(0.001I(R−1)Pt _(E)+50(1−1/R)/V_(B)−0.12)]≦C _(PR)  (Eq. 20)

A warning is given if C_(PO)<100.

Collect VolumesV _(CB) =V _(C)(1+f _(ACP))  (Eq. 21)V _(SPB) =V _(SP)(1+f _(ACP))  (Eq. 22)

The primary equation to be solved for purposes of the yield predictionby the prediction model is Eq. 4. Consequently, Eqs. 1-3 and 5-22 areancillary to Eq. 4 although they may be used to calculate other outputdata and/or information required by Eq. 4. With regard to the manner inwhich Eqs. 1-22 are solved, all the iteration loops are preferably basedon the technique of successive approximation, in which each iteration isa repeat of the previous one, but using updated parameter valuescalculated in the previous iteration. This process continues until allthe convergence criteria are met. The convergence criteria are that, onsuccessive iterations, the variable difference is ≦1 for V_(c), ≦0.2 fort_(E), and <0 for C_(B).

As noted above, the foregoing was based upon a dual needle configurationas illustrated in FIG. 7A. In the event that a single needleconfiguration such as that illustrated in FIG. 7B is utilized, thefollowing Eq. 7′ is used in place of Eq. 7 and the constants C₁ and C₂for Eq. 5 are as follows:C₁=0.803C₂=8.54×10⁻⁵t _(E) =t _(P) , Q _(IN)≦20t _(E) =t _(P)−215(1/20−1/Q _(IN)), Q _(IN)>20  (Eq. 7′)

Variables Index.

Symbols for Equations:

-   C₁, C₂=constants in platelet collection efficiency equations.-   C_(B)=platelet concentration in collect bag, expressed as 103    platelets/microliter.-   C_(PO)=donor post-count, expressed as 103 platelets/microliter.-   C_(PR)=donor pre-count, expressed as 103 platelets/microliter.-   E_(C)=platelet collection efficiency.-   f_(ACP)=AC expressed as a fraction of pure plasma volume.-   f_(BP)=fraction of V_(B) processed in platelet collection procedure.-   f_(SP)=V_(CON) expressed as a fraction of V_(B).-   F_(Y)=user-specific (e.g., blood bank/center) yield calibration    factor.-   H=hematocrit of donor or patient.-   I=AC infusion rate constant.-   L=donor or patient height, inches.-   P=plasma collect factor.-   Q_(AC)=AC flow, ml/min.-   Q_(ACD)=AC flow infused into donor for platelet collection    procedures, ml/min.-   Q_(IN)=inlet flow, ml/min.-   Q_(INA)=average inlet flow for platelet procedures, ml/min.-   Q_(INO)=RQ_(ACD)=inlet flow associated with Q_(ACD), ml/min.-   R=AC ratio.-   t_(E)=equivalent procedure time, min.-   t_(P)=procedure time, min.-   V_(B)=total blood volume of donor or patient, ml.-   V_(C)=volume of pure plasma in platelet collect bag, ml.-   V_(C)=total volume in platelet collect bag, ml.-   V_(CON)=volume constraint for total pure plasma collected, ml.-   V_(CONH)=higher value of V_(CON), ml.-   V_(CONL)=lower value of V_(CON), ml.-   V_(SP)=volume of pure plasma in source plasma bag, ml.-   V_(SPB)=total volume in source plasma bag, ml.-   W=donor or patient weight, lbs.-   W_(C)=weight constraint associated with V_(CON), lb.-   Y=platelet yield, number of platelets.

As noted above, the computer/database assembly 140 associated withprinciples of the present invention interfaces with or at least providesinformation to one or more blood component collection assemblies 10 toprovide a blood component collection system 2. That is, although thereare definite advantages to having an interface between thecomputer/database assembly 140, and the blood component collectiondevice 18, the optimization procedure may be performed at any locationand input into the blood component collection device 18 in any manner.Since the general principles of the blood component collection assembly10 were described with relation to the collection assemblies 10′, 10″(FIGS. 7A and 7B) which included the blood component collection device18 and its various features, the computer/database assembly 140 will bedescribed in relation to such assemblies 110′, 10″. However, it will beappreciated that the fundamental optimization principles of the presentinvention are not limited to these collection procedures and/orapparatus.

As noted (FIGS. 1A-1D), the computer/database assembly 140 generallyincludes a central station 148, as well as a manipulation device 144 anda memory device 142 (not separately shown). Initially, it should benoted that the manipulation device 144 is preferably separate from theinternal control of the blood component collection device 18. Device 18also preferably remains accessible by the operator interface device 16(which could include the touch screen introduced above). However,typically the manipulation device 144 will be integrated with (e.g., putin data communication relationship with) this internal control device16. The central memory device may also be separate from the centralmanipulation device 144 (as well as from the individual blood processingmachines 10 and/or their control elements 16). The memory device needonly be put in data communication relationship with the datamanipulation device 144 and/or one or more control elements of thecentral computational/database assembly 140 and/or one or more bloodprocessing machines 10.

Referring now to FIG. 9A, the computational/database assembly 140 willbe described with regard to a standard exemplary procedure. The centralinput station 148 will typically be used by blood banks/centers as theprimary means for donor data input and donor data management. Asintroduced above in the relation to FIGS. 2A-2E, information relating toa donor such as gender, height, weight, total blood volume, blood type,temperature, pressure and demographics will preferably be input at thecentral input station 148, or could be easily downloaded to thecomputer/database assembly 140 from a disparate system such as systems 3and/or 4 as shown in FIG. 1B. Moreover, information relating to thedonor's hematocrit and a blood component pre-count (such as plateletpre-count), both of which may be obtained from a donor blood sample anddetermined by known techniques such as cell counters, may also beentered at the central station 148. In addition to donor-related data,the particular type of collection procedure to be used for the donor(e.g., single needle or double needle) may be input/confirmed at thecentral input station 148. These also could be downloaded from adisparate system. Based upon this information and certainsite-standardized conditions (e.g., total procedure time, collectionefficiency, AC infusion rate), an initial procedure order is thereaftergenerated preferably by the manipulation device 140, which specifies thevarious process control parameters associated with the selectedcollection procedure.

The initial procedure order may be transferred/down-loaded onto theinternal control of a blood component collection device 18 by a computernetwork system (FIGS. 1A and 1B) or by other methods such s floppy disktransfer (not shown). The operator interface module 16 may be used toassist this process if required/desired. When this operator interfacemodule 16 exists, it may of course still be used as an alternative forthe initial donor data input and/or to generate the initial procedureorder including optimization and thereby alleviate the need for acentral input station 148. However, it is believed that it will be moreefficient to use the central input station 148 and the associatedcentral data manipulation device 140, preferably in conjunction with thecentral memory database. Although this initial procedure order may beused in the collection process, the initial procedure order may also beoptimized in accordance with principles of the present invention toobtain one or more optimal values for the process control parameters.This optimization may also be performed on the individual bloodprocessing machines 18, but is preferably conducted on/by the centraldata manipulation device 140. As noted, this optimization process may beutilized before the collection procedure is actually initiated, but mayalso be initiated during a given collection procedure and such isreferred to as downstream optimization although if performed afterinitiation, and though possibly performed at the centralcomputer/database 140 on/by manipulation device 140, it is preferredthat post-initiation changes be effected only at or by the individualmachines 10.

With regard to the various optimization options, process controlparameters may be derived for a product-based optimization. Moreparticularly, the computer/database assembly 140 and specifically themanipulation device 144 derives process control parameters for achievinga predetermined yield of blood components through a maximization of atleast one process parameter as will be discussed below in relation tothe optimization models 152 (FIG. 9B), and 172 (FIG. 9C), for example,as noted above, in the United States a single platelet product (SPP) is3×1 011 platelets and a double platelet product (DPP) is 6×1 011platelets. Consequently, the manipulation device 144 may be configuredto provide a number of product-based optimizations such as SPP and DPP.Although the exact values for a current U.S. SPP and DPP could beconfigured into the manipulation device 144, in order to increase theprobability that the actual yield will equal or exceed the yieldrequirements for a current U.S. SPP or a DPP, the site may configure aSPP to be 3.5×1 011 platelets and a DPP to be 7.0×1011 platelets (e.g.,to effectively provide a given confidence level over the minimum thatthe specified yield will actually be met).

The manipulation device 144 may also be configured to provide atime-based optimization. That is, for a given amount of time for which adonor is available, the manipulation device 144 will derive thoseprocess parameters that allow for the collection of a “maximum” amountof platelets in this time period in relation to a maximization of atleast one of the process control parameters.

Once the optimization is complete, the values for the various processcontrol parameters generated thereby, as well any ancillary/previouslyspecified values, are downloaded to the internal control of the bloodcollection device 18 such that the collection procedure may be initiatedor reinitiated (downstream optimization) as the case may be inaccordance with these values. Once the procedure is completed, certaindata is transferable (electronically through the communication subsystem146 or otherwise as noted, e.g., floppy disk) back to the manipulationdevice 144 and/or the central memory/database and/or the central inputstation 148 for further use with regard to the particular donor. Inaddition, this information as well as the initial input may be used togenerate various types of reports, which may further assist in themanagement of the blood bank/center (e.g., individual run,donor/patient, summary reports, etc.). That is, this information may beused in the derivation of subsequent procedure orders for the particulardonor or even for improved efficiency for entire pool of donors. Forinstance, in the event that a certain AC infusion rate was used in thecollection procedure which had certain effects on this particular donor,this may be recorded in the central memory/database 142 such that alower AC infusion rate would be suggested/required for subsequentdonations by this donor and perhaps also for the entire pool.

One model which may be incorporated into the manipulation device 144 isillustrated in FIG. 9B and will be described with regard to plateletcollections in accordance with the dual needle configuration of FIG. 7A,although the device 144 may be used with a variety of other collectionprocedures and including the single needle configuration of FIG. 7B, aswell as with various other blood components. Initially, it should benoted that all references in FIG. 9B to “derivations” are actuallyprovided by the prediction model discussed above such that there iseither an appropriate communication interface between the predictionmodel and manipulation device 144 or the manipulation device 144actually includes the prediction model disposed thereon or therein.Moreover, as noted the prediction model described here is specific tothe blood component collection machine 18 and to platelet collections.Therefore, if other machines are used, the associated prediction modelwould also likely change as noted. Moreover, the associated predictionmodel may also vary in the case where different blood components such asred blood cells are to be collected.

The optimizer model 152 of FIG. 9B may be used for both product-basedand time-based optimizations. Initially, the optimizer model 152 will bedescribed with regard to a product-based optimization. That is, thefundamental premise of the optimization is to achieve a predeterminedplatelet (or other blood component type) yield (or within a yieldrange), preferably in the minimum amount of time.

The optimizer model 152 of FIG. 9B is comprised of four iterative loops.Generally, the first loop 156 is a derivation of an inlet flow (Q_(IN))associated with a specified AC infusion rate (I_(SPEC)) which istypically set at a maximum value for purposes of the present inventionand which is entered at the input station 154. This derivation isthereafter performed by the processing station 158 and includes thesolution of Eqs. 4, 8,14, and 16 and/or equations ancillary thereto bythe prediction model as discussed above.

There are of course various convergence criterion/criteria, which may beincorporated into the first loop 156. For instance, convergence may bebased upon the current inlet flow (Q_(IN-C)) in the first loop 156through use of a binary search technique. In this case, in solving thenoted equations at the processing station 158 certain parameters remainfixed in the iterative derivation of the inlet flow (Q_(IN)) thatachieves the specified AC infusion rate (I_(SPEC)) and these parametersare also specified at input station 154. These include the total bloodvolume (V_(B)) which can be calculated using Eq. 10 since the donor'sheight, weight, and gender are entered at the central input station 148,and the AC ratio (R), which can be calculated using Eq. 9 since thedonor's hematocrit (H) has been determined, or may be specified at somevalue. Moreover, the total procedure time (t_(P)) remains fixed in eachiterative derivation of the inlet flow (Q_(IN)) associated with thespecified AC infusion rate (I_(SPEC)) in the first loop 156. However,since the total procedure time (t_(P)) is not known in the case of aproduct-based optimization and thus cannot be specified at the inputstation 154, a current total procedure time (t_(P-C)) initially will beassumed (e.g., this assumption is configured in the optimizer model 152and since a range of total procedure times is provided in the predictionmodel 20 as noted above, the mean total procedure time (t_(P)) istypically configured into this portion of the optimizer model 152 as theinitial current total procedure time (t_(P-C))). The “current”designation is used for the total procedure time in this case since theoptimizer model 152 provides for an adjustment of the total proceduretime after each iterative determination of the inlet flow (Q_(IN)) whichprovides the specified AC infusion rate (I_(SPEC)) in the second loop160 in order to achieve the desired yield (Y) if required in the case ofa product-based optimization as will be discussed in more detail below.

Generally, the inlet flow-based binary search technique convergence maybe provided by assuming a current value for the inlet flow (Q_(IN-C)),calculating a current plasma collect factor (P_(C)) using the currenttotal procedure time (t_(P-C)), calculating a current AC infusion rate(I_(C)) using the current inlet flow (Q_(IN-C)) and current plasmacollect factor (P_(C)), and adjusting the current inlet flow (Q_(IN-C))(at the parameter update in the first loop 156) in accordance with theselected binary search technique until there is a predeterminedconvergence between the two most recent values for the current inletflow (Q_(IN-C)) (i.e., wherein the difference between the two mostrecent values of Q_(IN-C) is less than some predetermined amount whichmeans that the convergence criterion is met). In the case of a binarysearch technique, there will always be convergence (i.e., theconvergence criterion will always be met) such that the optimizer model152 will always exit the first loop 156 and enter the second loop 160.

As an alternative to the noted inlet flow-based convergencecriterion/criteria and the noted binary search technique, anotherpossibility is to base convergence on the specified AC infusion rate(I_(SPEC)) and use an iterative derivation to determine the desiredinlet flow (Q_(IN)). In this case, the first loop 156 is used to onceagain iteratively derive the inlet flow (Q_(IN)), which provides thespecified AC infusion rate (I_(SPEC)) at the processing station 158 fromcertain specified parameters. That is, the first loop 156 is still amaximization of the inlet flow (Q_(IN)) based upon the specified ACinfusion rate (I_(SPEC)), which should be associated with the donor 14.This is again primarily through the solution of Eqs. 4, 8, 14, and 16and/or equations ancillary thereto by the prediction model discussedabove.

For purposes of solving the above-identified equations in relation tothe infusion rate-based convergence criterion, certain parameters remainfixed in the iterative derivation of the inlet flow (Q_(IN)), whichachieves the specified AC infusion rate (I_(SPEC)) in the first loop 156and these parameters are also specified at the input station 154. Theseinclude the specified AC infusion rate (I_(SPEC)), which is known andwhich is typically a maximum value for the donor 14, the total bloodvolume (V_(B)) which can be calculated using Eq. 10 since the donor's 14height, weight, and gender are entered in the central input station 148or downloaded from a disparate information database, and the AC ratio(R) which can be calculated using Eq. 9 since the donor's 14 hematocrit(H) has been determined and input in the central input station 148 orotherwise downloaded, or may be entered as modified input data.Moreover, the total procedure time (t_(P)) remains fixed in eachiterative derivation of the inlet flow (Q_(IN)) associated with thespecified AC infusion rate (I_(SPEC)). However, once again the totalprocedure time (t_(P)) is not known in the case of a product-basedoptimization and thus cannot be specified at the input station 154.Therefore, a current total procedure time (t_(P-C)) initially will beassumed (e.g., this assumption is configured in the optimizer model 152,and since a range of total procedure times is provided in the predictionmodel as noted above, the mean total procedure time (t_(P)) is typicallyconfigured into the first loop 156 of the optimizer model 152). The“current” designation for the total procedure time is used for theabove-identified reasons relating to the adjustment of the totalprocedure time in the second loop 160 if required to attain the desiredyield (Y).

The solution of Eqs. 4, 8, 14, and 16 also requires that certain valuesbe assumed for certain of the remaining parameters with still otherparameters being derived from this assumption. In this case, aniterative procedure is used and updated/current values are used in thenext iterative calculation(s). All parameters that change on eachiteration of the first loop 156 are identified herein with a “c”subscript to designate that the most current value is to be used.Although the derivation of that inlet flow (Q_(IN)) which provides thespecified AC infusion rate (I_(SPEC)) may be accomplished in a varietyof manners via Eqs. 4, 8, 14, and 16, one way is to assume a currentvalue for the plasma collect factor (P_(C)), then calculate the currentinlet flow (Q_(IN-C)) using the specified AC infusion rate (I_(SPEC)),then calculate the current yield (Y_(C)), then calculate the currentplasma collection factor (P_(C)) using the current yield (Y_(C)), andrepeat this procedure with the current values until there has beenacceptable convergence on the current inlet flow (Q_(IN-C)) in relationto the specified AC infusion rate (I_(SPEC)) (e.g., when the particularconvergence criteria are met). When there is acceptable infusionrate-based convergence, the optimizer model 152 exits the first loop 156and enters the second loop 160. In order to offer protection for caseswhen there is no such convergence, a maximum number of iterations forthe first loop 156 may be specified (not shown).

The second loop 160 of the optimizer model 152 is a total procedure time(t_(P)) iteration. That is, the second loop 160 is an iterativeadjustment of the current total procedure time (t_(P-C)). Initially, inthe second loop 160 and in the case of a product-based optimization themodel 152 will never exit at the first comparator 162 since a totalprocedure time (t_(P)) is not specified at the input station 154.Consequently, the optimizer model 152 proceeds to the second comparator166 where convergence criteria (i.e., more than one check) is made. Oneconvergence criterion that is checked at the second comparator 166 iswhether the current yield (Y_(C)) is greater than or equal to thedesired and specified yield (Y). In this case, the current yield (Y_(C))may be calculated based upon the values specified at the input station158, values derived at the processing station 158, and the current totalprocedure time (t_(P-C)) for comparison with the desired and specifiedyield (Y) (in some cases, this current yield calculation (Y_(C)) mayhave been performed in the first loop 156 and need not be repeated inthe second loop 160). If the yield convergence criterion is met, themodel 152 exits the second loop 160 and actually exits all the waythrough to the exit 151, as will be discussed below. In this case, thespecified/derived values are “optimal” and the collection procedurecould be performed on the device 18 using the noted values for thevarious control parameters.

In the event that the yield-based criterion is not met at secondcomparator 166, the second comparator 166 looks to a total proceduretime-based convergence criterion which may be similar to that discussedabove with regard to the inlet flow-based criterion (e.g., using abinary search technique with the convergence criterion then being apredetermined difference between the two most current values of thetotal procedure time (t_(P-C))). On the first time through the secondloop 160 after the noted yield-based convergence criterion has failedand the total procedure time convergence criterion has failed, thecurrent total procedure time (t_(P-C)) is adjusted and the model 152returns to the first loop 156. That is, each time that the current totalprocedure time (t_(P-C)) is adjusted in the second loop 160, theentirety of the first loop 152 is repeated (i.e., a new inlet flow(Q_(IN)) associated with the specified AC infusion rate (I_(SPEC)) isderived using the current total procedure time (t_(P-C)) provided by theadjustment in the second loop 160). Other convergence criterion/criteriacould be used in the second loop 160, such as specifying a maximumnumber of iterations to be performed by the second loop 160.

In the event that the yield-based convergence criterion is not met onthe second loop 160 and the total procedure time-based convergencecriterion is met at the second comparator 166 in the second loop 160,the optimizer model 152 exits the second loop 160 and enters the thirdloop 164. The third loop 164 is an iterative adjustment of the AC ratio(R). However, the model 152 initially enters the third comparator 169where convergence criteria (i.e., more than one) are checked. Oneconvergence criterion is again the above-noted yield-based convergencecriterion. If this yield-based convergence criterion is again not met,an AC ratio-based convergence criterion is checked at the thirdcomparator 169. This may be similar to the inlet flow-based criteriondiscussed above (e.g., using a binary search technique with theconvergence criterion being the two most current values of the ACratio). On the first time through the third loop 164 after theyield-based criterion has failed and the AC ratio-based convergencecriterion has failed, the AC ratio is adjusted and the optimizer model152 returns to the first loop 152. That is, each time that the AC ratio(R) is adjusted in the third loop 164, the entirety of the first andsecond loops 156, 160, respectively, is repeated. Other convergencecriteria could be used in the third loop 164, such as specifying amaximum number of iterations of the third loop 164.

In the event that the yield-based convergence criterion is not met inthe second or third loops 160,164, respectively, and the second andthird comparator 166, 169, respectively, and the AC ratio-basedconvergence criterion is met at the third comparator 169 in the thirdloop 164, the optimizer model 152 exits the third loop 164 and entersthe fourth loop 168. The fourth loop 168 is an iterative adjustment ofthe specified AC infusion rate (I_(SPEC)). However, the optimizer model152 initially enters the fourth comparator 170 where convergencecriteria (i.e., more than one) are checked. One convergence criterion isthe noted yield-based convergence criterion. If the noted yield-basedconvergence criterion is not met at the fourth comparator 170, an ACinfusion rate-based criterion is checked at the fourth comparator 170.This may be similar to the inlet-flow based criterion discussed above(e.g., using a binary search technique with the convergence criterionbeing the two most current values of the AC infusion rate). On the firsttime through the fourth loop 168 after the yield-based criterion hasfailed and the AC infusion rate-based convergence criterion has failed,the AC infusion rate is adjusted and the model 152 returns to the firstloop 152. That is, each time that the specified AC infusion rate(I_(SPEC)) is adjusted, the entirety of the first, second and thirdloops 156, 160, 164, respectively, is repeated (with the AC ratio setback to its initial value as entered at the input station 154 on eachiteration of the fourth loop 168). Other convergence criterion/criteriacould be used in the fourth loop 168, such as specifying a maximumnumber of iterations of the fourth loop 168. In cases where thespecified AC infusion rate (I_(SPEC)) is actually the maximum ACinfusion rate, typically the fourth loop 168 will execute only a singletime with a one-time increase in the AC infusion rate of, for instance,20% (e.g., may be site-configured).

In the foregoing loops where a yield-based convergence criteria areidentified, when the criteria are met the optimizer model 152 exits toexit 151 and the specified/derived (i.e., current) values for thevarious process control parameters may be provided to the device 18 forperforming the collection procedure. However, there may be cases whereno optimization occurs, such as when the optimizer model 152 exits tothe exit 151 based upon the AC infusion rate based convergence criterionbeing met.

The optimizer model 152 may also be used for a time optimization. Thatis, the optimizer model will derive optimal process parameters for apredetermined total procedure time (t_(P)) through maximization of atleast one of the process parameters in order to maximize the plateletcollection (or for other blood component types). In this case, theoptimizer model 152 only executes the first loop 156 to derive the inletflow (Q_(IN)) associated with a specified AC infusion rate (I_(SPEC))(typically a maximum value) using the input total procedure time (t_(P))in this iterative derivation instead of the assumed total procedure time(t_(P)) referenced above. Once there is acceptable convergence asdefined above in the product-based optimization such that model 152exits the first loop 156, the current yield (Y_(C)) may be calculated inthe first loop 156 (but again may already have been calculated in thefirst loop 156 at the processing station 158 such that no furthercalculation is required) and the convergence criterion will be met atthe first comparator 162 when entering the second loop 160 (i.e., in atime-based optimization when a total procedure time is specified at theinput station 154, the model 152 will exit when entering the second loop158). As a result, the inlet flow (Q_(IN)) and AC infusion rate (I) willbe optimal and the collection procedure may be performed with suchvalues.

Another optimization model is presented in FIG. 9C and may be used forboth product-based and time-based optimizations. As in the case of theoptimizer model 152, the optimizer model 172 may interface with theprediction model or actually integrally incorporate the predictionmodel, and thus reference to Eqs. 1-22 will be further made herein.Generally, the optimizer model 172 is based upon the principle thatoptimization occurs when an optimal inlet flow (Q_(L)) associated withan optimum system collection efficiency is used in the derivation ofvarious process control parameters. Referring to FIG. 10, arepresentative inlet flow (Q_(IN))/yield (Y) curve is presented to showthe optimal inlet flow (Q_(L)) associated with the maximum yield(Y_(MAX)). This optimal inlet flow (Q_(L)) is mathematically expressedby Eq. 23, presented below, which results from differentiating Eq. 4 ofthe prediction model with regard to the inlet flow (Q_(IN)). As can beappreciated, where different algorithms are used in the associatedprediction model (whether based upon collection of blood componentsother than platelets, different collection apparatus, or alternativederivations of the various parameters with the same collection procedureand apparatus), the optimal inlet flow may be mathematically expressedin a different manner.Q _(L)=(C1/2C ₂)e ^(−9.91(1−1/R)H) −C ₃  (Eq. 23).C ₃=1/(2(tp/K7−1/K9))Q ₀≧45 for Dual Needle (“DN”)  (Eq. 24)Q₀≧20 for Single Needle (“SN”)C ₃=0 Q ₀≦45 for DN  (Eq. 25)Q₀≦20 for SNK ₇=500(DN)K ₉=45(DN)  (Eq. 26)K ₇=215(SN)K ₉=20(SN)C ₁=0.803(SN, DN without stepdown)  (Eq. 27)C ₁=0.840(DN with stepdown)C ₂=4.08×10⁻⁵(DN)  (Eq. 28)C ₂=8.54×10⁻⁵(SN)

Based upon the foregoing, the optimal inlet flow (Q_(L)) is really“optimal” in terms of the collection apparatus.

Referring again to FIG. 9C, the optimizer model 172 will initially bedescribed with regard to a product-based optimization wherein thedesired yield (Y) is specified at input station 184. Generally, theinlet flow (Q_(IN)) associated with a specified AC infusion rate(I_(SPEC)) (typically the maximum AC infusion rate and also specified atinput station 184) is iteratively derived from certain other specifiedparameters. This inlet flow calculation, particularly when the maximumAC infusion rate (I_(MAX)) and maximum AC ratio (R_(MAX)) are specified,the inlet flow (Q_(IN)) is optimal based on the physiologicalconsiderations of the donor 14. This is primarily through the solutionof Eqs. 4, 8, 14, and 16 and/or equations ancillary thereto by theprediction model discussed above. For purposes of solving theseequations certain parameters remain fixed in the iterative derivation ofthe inlet flow (Q_(IN)), which achieves the specified AC infusion rate(I_(SPEC)) and these parameters are also specified at input station 184.These include the total blood volume (V_(B)) which can be calculatedusing Eq. 10 since the donor's height, weight, and gender are entered inthe central input station 148, and the AC ratio (R), which can becalculated using Eq. 9 since the donor's hematocrit (H) has beendetermined, or may be specified at some maximum value. Moreover, thetotal procedure time (t_(P)) remains fixed in each iterative derivationof the inlet flow (Q_(IN)) associated with the specified AC infusionrate (I_(SPEC)). However, since the total procedure time (t_(P)) is notknown in the case of a product-based optimization and thus cannot bespecified at the input station 184, a current total procedure time(t_(P-C)) initially will be assumed (e.g., this assumption is configuredin the optimizer model 172 and since a range of total procedure times isprovided in the prediction model as noted above, the mean totalprocedure time (t_(P)) is typically configured into this portion of theoptimizer model 172 as the initial current total procedure time(t_(P-C))). The “current” designation is used for the total proceduretime in this case since the optimizer model 172 provides for anadjustment of the total procedure time after each iterativedetermination of the inlet flow (Q_(IN)) which provides the specified ACinfusion rate (I_(SPEC)) in order to achieve the desired yield (Y) ifrequired in the case of a product-based optimization as will bediscussed in more detail below.

The solution of Eqs. 4, 8, 14, and 16 also requires that certain valuesinitially be assumed for certain of the remaining parameters. In thiscase, an iterative procedure is used in the solution of the yieldequation (Eq. 4) (and including equations ancillary thereto as notedabove) and updated values are used in the next iterative calculation(s)at the processing station 188. Although the derivation of that inletflow (Q_(IN)) which provides the specified (typically maximum) ACinfusion rate (I_(SPEC)) may be accomplished in a variety of manners viaEqs. 4, 8, 14, and 16, one way is to assume a current value for theplasma collect factor (P), then calculate the current inlet flow(Q_(IN-C)) using the specified AC infusion rate (I_(SPEC)), thencalculate the current yield (Y_(C)), then calculate the current plasmacollection factor (P_(C)) using the current yield (Y_(C)), and repeatthe foregoing with the updated parameters, all within the processingstation 188, until there has been acceptable convergence on the currentinlet flow (Q_(IN-C)) in relation to the specified AC infusion rate(I_(SPEC)).

In addition to the calculation of the current inlet flow (Q_(IN-C))associated with the specified AC infusion rate (I_(SPEC)), theabove-discussed optimal inlet flow (Q_(L)) is calculated at processingstation 192. Consequently, a comparison can be made between the currentinlet flow (Q_(IN-C)), which was derived in the above-described mannerand the optimal inlet flow (Q_(L)) at the first comparator 176. If thecurrent inlet flow (Q_(IN-C)) is less than the optimal inlet flow(Q_(L)) at the first comparator 176, the specified values for thevarious parameters associated with the inlet flow Q_(IN) are “optimum”,namely the AC ratio (R) and the AC infusion rate (I) specified at theinput station 184. Thereafter, the current yield (Y_(C)) (which wascalculated in the derivation of the current inlet flow (Q_(IN-C))associated with the specified AC infusion rate (I_(SPEC)) at theprocessing station 188) is compared with the input yield (Y) at secondcomparator 180. In the event that there has been acceptable convergencebetween these yield values, the current total procedure time (t_(P-C))is also “optimal”. However, in the event that there has not beenacceptable convergence between these yield values, the current totalprocedure time (t_(P-C)) is adjusted at adjusting station 196 and theforegoing iterative derivation of the current inlet flow (Q_(IN-C))associated with the specified AC infusion rate (I_(SPEC)) is repeateduntil such convergence is achieved (i.e., using the initially specifiedAC infusion rate (I_(SPEC)) and the now adjusted current total proceduretime (t_(P-C)), a new current inlet flow (Q_(IN-C)) is iterativelyderived in the above-described manner).

Referring back to the first comparator 176, if the current inlet flow(Q_(IN-C)) associated with the specified AC infusion rate (I_(SPEC))derived at processing station 188 is greater than the optimal inlet flow(Q_(L)), a current AC infusion rate (I_(C)) associated with thisparticular inlet flow (Q_(L)) is iteratively derived at the processingstation 188 generally in the above-described manner (i.e., the initiallyspecified AC infusion rate (I_(SPEC)) is disregarded in this derivationand a current AC infusion rate (I_(C)) is iteratively derived tocoincide with the inlet flow (Q_(L))). In this case, the current inletflow (Q_(IN-C)) will always be equal to the optimal inlet flow (Q_(L))at the first comparator 176 and the optimizer model 172 thereafterproceeds to the second comparator 180 for the yield comparison inaccordance with the above-described procedure.

The optimizer model 176 may also be used for a time-based optimization.In this case, the total procedure time (t_(P)) is specified at the inputstation 184 as a specified total procedure time (t_(P-SPEC)) and thus isnot assumed as in the product-based optimization. The optimizer model172 thereafter proceeds in the same manner discussed above with regardto the product-based optimization except at the second comparator 180.Since no yield was input there is no yield comparison made at the secondcomparator 180. Instead a total procedure time comparison is made at thesecond comparator 180. Since the current total procedure time (t_(P-C))was set equal to the specified total procedure time (t_(P-SPEC)) priorto the model 172 proceeding to the processing station 188 in thistime-based optimization, the model 172 will exit each time at the secondcomparator for a time-based optimization.

In addition to the above-described product-based and time-basedoptimizations, the principles of the present invention may be extendedto other applications relating to enhancing blood component systemmanagement. For instance, an optimization in accordance with principlesof the present invention may be extended to encompass donor managementissues. In one such case, another “optimization” associated with theblood component collection process would be to collect blood componentsas dictated by existing inventory (i.e., use optimization as aninventory control). That is, information relating to the inventory ofthe various types of blood components in the blood bank or the demandfor one or more blood component types could be maintained such thatspecific collection procedures could be selected to accommodate for alow supply of a given blood component type or a high demand for suchblood component type. More specifically, in the event that the supply ofred blood cells was low and/or the demand for red blood cells was high,or anticipated to be so in the near future, prompts could be provided tooperators that red blood cells should be selected for collection ifpossible from donors during a given time period. Relatedly, theoptimization principles of the present invention would be applicable tomaintaining data on blood component collections from a given donor suchthat a determination could be made as to what type or types of bloodcomponents from the particular donor provided the maximum yield in thecollection procedure. That is, information could be collected andmaintained from prior blood component donations such that adetermination could be made for a specific donor as to which type ortypes of blood components the donor has had a propensity to producemaximum yields therefor.

Notwithstanding the foregoing description of the present invention inrelation to an on-line blood component collection process, those skilledin the art will appreciate that the source of blood may be provided tothe blood component collection device from an appropriate bloodcontainer (not shown) interconnected with the blood component collectiondevice 18 versus receiving such directly from a human donor. Moreover,the blood of course may be provided from alternative sources such asanimals. Furthermore, as illustrated in FIG. 7B the described component(platelet, RBC, plasma, inter alia) harvesting procedure may beperformed utilizing a single needle configuration. In addition, thepresent invention is applicable to the collection of other types ofblood components such as red blood cells, stem cells, white blood cells,and/or plasma, and is further applicable to the simultaneous collectionof more than one blood component type. In the case of red blood cellcollection and optimization in accordance with principles of the presentinvention, the donor's blood type should be known and used in variousalgorithms. Moreover, the present invention is not limited to the sourcebeing whole blood. That is, the principles of the present invention maybe applicable to removal of a component from any composite liquid, i.e.any liquid containing separable components (preferably separable usingmechanical procedures.

The foregoing description of the present invention has been presentedfor purposes of illustration and description. Although the preferredembodiment of the invention has been described in language which may bethought specific to structural features, methodological acts, andcomputer readable media containing such acts, it is rather intended tobe understood that the invention defined in the appended claims is notnecessarily limited to the specific structure, acts or media sodescribed. The specific structure, acts or media are disclosed aspreferred forms of implementing the claimed invention. Consequently,variations and modifications commensurate with the above teachings, andskill and knowledge of the relevant art, are within the scope of thepresent invention. The embodiments described hereinabove are furtherintended to explain best modes known of practicing the invention and toenable others skilled in the art to utilize the invention, and suchother embodiments, and with various modifications required by theparticular applications or uses of the present invention. It is intendedthat the appended claims be construed to include alternative embodimentsto the extent permitted by the prior art.

1. An extracorporeal blood processing information management systemcomprising: a central database, said central database containinginformation concerning demand for selected blood products; a data inputdevice connected in data communication relationship with said centraldatabase; a data manipulation device connected in data communicationrelationship with at least one of said central database and said datainput device; and a communication subsystem connected in datacommunication relationship with at least one of said central database,said data input device and said data manipulation device; and at leastone extracorporeal blood processing machine; said communicationsubsystem being connected in data communication relationship with saidat least one extracorporeal blood processing machine to provide for datacommunication to and from said at least one extracorporeal bloodprocessing machine; and said communication subsystem communicating datato said at least one extracorporeal blood processing machine, said databeing preparation data which is generated by said data manipulationdevice and is used by said at least one extracorporeal blood processingmachine in preparation of said at least one machine for anextracorporeal blood processing procedure, said preparation data beinggenerated, at least in part, based on said information concerning demandfor selected blood products.
 2. The extracorporeal blood processinginformation management system of claim 1 further comprising means forselecting blood products based on need for blood products of a bloodproduct supplier.
 3. The extracorporeal blood processing informationmanagement system of claim 2 further comprising means for excludingprocedures for processing blood if blood products resulting from saidexcluded procedures would not meet a need for blood products of a bloodproduct supplier.
 4. The extracorporeal blood processing informationmanagement system of claim 3 further comprising means for displaying alist of available blood processing procedures, said blood processingprocedures being compatible with an available donor and producing bloodproducts needed by a selected blood product supplier on the basis ofdata for said available donor and for said blood product supplier insaid central database.
 5. The extracorporeal blood processinginformation management system of claim 4 wherein said means fordisplaying displays unavailable procedures, available procedures andpossible procedures.
 6. The extracorporeal blood processing informationmanagement system of claim 5 wherein said data manipulation devicefurther comprises means for assigning a donor from a list of availabledonors to a blood processing machine from a list of blood processingmachines and for transferring preparation data for an optimized bloodcollection process for said assigned donor to said assigned machine. 7.The extracorporeal blood processing information management system ofclaim 6 wherein said means for assigning comprises a video displayhaving a set of images associated with each of said available donors anda set of images associated with each of a said blood processing machinesand means for connecting an image associated with a donor with and imageassociated with a blood processing machine.
 8. The extracorporeal bloodprocessing information management system of claim 7 wherein said datamanipulation means further comprises means for monitoring the status ofblood processing procedures being performed by a plurality of bloodprocessing machines.
 9. The extracorporeal blood processing informationmanagement system of claim 1 wherein said data manipulation meansfurther comprises means for monitoring the status of blood processingprocedures being performed by a plurality of blood processing machines.10. An extracorporeal blood processing information management systemadapted to be used with at least one extracorporeal blood processingmachine, said system comprising: a central database, said centraldatabase containing information concerning demand for selected bloodproducts; a data input device connected in data communicationrelationship with said central database; a data manipulation deviceconnected in data communication relationship with at least one of saidcentral database and said data input device; and a communicationsubsystem connected in data communication relationship with at least oneof said central database, said data input device and said datamanipulation device; said communication subsystem being also adapted tobe connected in data communication relationship with at least oneextracorporeal blood processing machine to provide for datacommunication to and from said at least one extracorporeal bloodprocessing machine; and said communication subsystem being adapted tocommunicate data to said at least one extracorporeal blood processingmachine, said data being preparation data which is generated by saiddata manipulation device and is used by said at least one extracorporealblood processing machine in preparation of said at least one machine foran extracorporeal blood processing procedure, said preparation databeing generated, at least in part, based on said information concerningdemand for selected blood products.
 11. The extracorporeal bloodprocessing information management system according to claim 10 wherebysaid preparation data is derived from data communicated from said datainput device to said data manipulation device.
 12. The extracorporealblood processing information management system according to claim 10 inwhich run data is communicated by said communication subsystem from saidat least one extracorporeal blood processing machine during saidprocedure.
 13. The extracorporeal blood processing informationmanagement system according to claim 12 in which said run datarepresents information about an extracorporeal blood processingprocedure collected after completion of said procedure.
 14. Theextracorporeal blood processing information management system accordingto claim 12 in which said run data is communicated to said at least oneextracorporeal blood processing machine and used by said at least oneextracorporeal blood processing machine in preparation of said at leastone machine for a discrete, subsequent extracorporeal blood processingprocedure.
 15. The extracorporeal blood processing informationmanagement system according to claim 12 in which said run data iscommunicated by said communication subsystem to said central database tocreate stored run data.
 16. The extracorporeal blood processinginformation management system according to claim 15 in which said storeddata is communicated by said communication subsystem to said datamanipulation device which manipulates said stored data to createpreparation data which is communicated to one of said at least oneextracorporeal blood processing machine which uses said preparation datain preparation of said one of said at least one machine for a discrete,subsequent extracorporeal blood processing procedure.
 17. Theextracorporeal blood processing information management system accordingto claim 10 in which a report may be generated.
 18. The extracorporealblood processing information management system according to claim 10 inwhich said preparation data is manipulated by said manipulation deviceto create manipulated preparation data.
 19. The extracorporeal bloodprocessing information management system according to claim 18 in whichsaid manipulated preparation data comprises optimized preparation dataas a result of an optimization manipulation performed by saidmanipulation device.
 20. The extracorporeal blood processing informationmanagement system according to claim 10 in which said central databasereceives previously stored data from a discrete information managementsystem, and wherein said previously stored data is communicated by saidcommunication subsystem to said data manipulation device whichmanipulates said previously stored data to create said preparation data.21. The extracorporeal blood processing information management systemaccording to claim 20 in which said preparation data comprises optimizedpreparation data as a result of an optimization manipulation performedby said manipulation device.
 22. The extracorporeal blood processinginformation management system according to claim 10 which furthercomprises computer program product including: a module for collectingdonor data; a module for collecting information concerning demand forselected blood products; a module for manipulating said donor data andsaid information concerning demand for selected blood products; a modulefor assigning a donor to an extracorporeal blood processing system; anda module for finalizing an extracorporeal blood procedure.
 23. Theextracorporeal blood processing information management system accordingto claim 22 in which said module for collecting donor data includes oneor more sub-procedures that prompt a user to enter data.
 24. Theextracorporeal blood processing information management system accordingto claim 22 in which said module for collecting donor data includes oneor more sub-procedures that provide for receiving donor data stored in adiscrete storage medium.
 25. The system according to claim 22 whereinsaid module for manipulating donor data includes one or more facilitieswhich provide for optimizing donor data to create optimized donor data.26. The system according to claim 22 wherein said module formanipulating donor data includes one or more facilities which providefor manipulating said optimized donor data to create manipulated donordata.
 27. The system according to claim 16 whereby said module forcollecting data and said module for manipulating data are used to obtaina prediction of a procedure which a donor is qualified to undergo. 28.The system according to claim 22 wherein said module for assigning adonor to an extracorporeal blood processing system includes one or morefacilities which provide for determining the availability of a donor tobe assigned to an extracorporeal blood processing system.
 29. The systemaccording to claim 22 wherein said module for assigning a donor to anextracorporeal blood processing system includes one or more facilitieswhich provide for determining the availability of an extracorporealblood processing system to which a donor may be assigned.
 30. The systemaccording to claim 22 wherein said module for finalizing anextracorporeal blood procedure includes one or more facilities thatprovide for monitoring a procedure.
 31. The system according to claim 22wherein said module for finalizing an extracorporeal blood procedureincludes one or more facilities that provide for finalizing a procedure.32. The system according to claim 22 wherein said module for finalizingan extracorporeal blood procedure includes one or more facilities thatprovide for generating a report on a procedure.
 33. The system accordingto claim 22 further comprising a module for monitoring a procedure. 34.The system for performing an extracorporeal blood collection procedureaccording to claim 22 further comprising a reporting module forgenerating reports.
 35. The system for performing an extracorporealblood collection procedure according to claim 22 which further comprisesa reporting module for administrating parameters to be used in at leastone of said module for collecting donor data; said module formanipulating said donor data; said module for assigning a donor to anextracorporeal blood processing system; and said module for finalizingan extracorporeal blood procedure.
 36. A method for managingextracorporeal blood processing comprising the steps of: receivingstored donor data from a storage medium; receiving data concerningrelative need for selected blood products; manipulating said storeddonor data and said data concerning relative need for selected bloodproducts using a data manipulation device to obtain manipulated data,communicating said manipulated data from said data manipulation deviceto an extracorporeal blood processing machine; and performing anextracorporeal blood processing procedure using said manipulated data.37. A method for performing an extracorporeal blood collection procedureincluding the steps of: collecting donor data; collecting dataconcerning relative need for selected blood products; manipulating saiddonor data and said need data to create manipulated donor data;assigning a donor to an extracorporeal blood processing system includingsending said manipulated donor data to the extracorporeal bloodprocessing system; running an extracorporeal blood collection procedureusing said manipulated donor data and creating run data; and finalizingan extracorporeal blood collection procedure.
 38. The method accordingto claim 37 wherein said step of collecting data concerning relativeneed includes receiving donor data from a storage medium, and whereinsaid step of manipulating said donor data includes manipulating thedonor data received from said storage medium.
 39. The method accordingto claim 37 wherein said step for collecting data concerning relativeneed includes one or more facilities for prompting a user to enter data.40. The method according to claim 37 wherein said step for manipulatingdonor data includes one or more facilities which provide for optimizingdonor data to create optimized donor data and for manipulating said dataconcerning relative need and said optimized donor data to identifypreferred procedures.
 41. The method according to claim 37 whereby saidstep for collecting donor data, said step for collecting data concerningrelative need for selected blood products, and said step formanipulating data are used to obtain a prediction of a procedure which adonor is qualified to undergo.
 42. The method according to claim 37wherein said step for assigning a donor to an extracorporeal bloodprocessing system includes one or more facilities which provide fordetermining the availability of a donor to be assigned to anextracorporeal blood processing system.
 43. The method according toclaim 37 wherein said step for assigning a donor to an extracorporealblood processing system includes one or more facilities which providefor determining the availability of an extracorporeal blood processingsystem to which a donor may be assigned.
 44. The method according toclaim 37 wherein said step for finalizing an extracorporeal bloodprocedure includes one or more facilities which provide for monitoring aprocedure.
 45. The method according to claim 37 wherein said step forfinalizing an extracorporeal blood procedure includes one or morefacilities that provide for finalizing a procedure.
 46. The methodaccording to claim 37 wherein said step for finalizing an extracorporealblood procedure includes one or more facilities which provide forgenerating a report on a procedure.
 47. The method according to claim 37further comprising a step for monitoring a procedure.
 48. The methodaccording to claim 37 further comprising a step for generating reports.49. The method according to claim 37 which further comprises a step foradministrating parameters to be used in at least one of said steps forcollecting donor data; for manipulating said donor data; for assigning adonor to an extracorporeal blood processing system; and for finalizingan extracorporeal blood procedure.
 50. The method according to claim 37in which each of said steps may be performed at any time during anextracorporeal blood processing procedure.
 51. The method according toclaim 37 in which said step for collecting donor data produces achecked-in donor record which contains said donor data; said checked-indonor record being used by said step for manipulating donor data tocreate manipulated donor data.
 52. The method according to claim 37 inwhich said step for manipulating produces a manipulated donor datarecord which contains said manipulated donor data; said manipulateddonor data record being used by said step for assigning a donor to anextracorporeal blood processing machine to assign a donor to a machine.53. A system for performing an extracorporeal blood collection procedureincluding a computer program product comprising: a module for collectingdonor data; a module for collecting need data concerning need forselected blood products; a module for manipulating said donor data andsaid need data; a module for selecting an extracorporeal bloodprocessing procedure based on said manipulated donor data and need data;and a module for assigning a donor to one of one or more extracorporealblood processing systems; and a module for finalizing saidextracorporeal blood processing procedure.
 54. A method for managingextracorporeal blood processing activities comprising the steps of:using a centralized system to run a prediction using donor data and needdata concerning need for selected blood products; obtaining a predictionof a yield for a extracorporeal blood procedure for which a donor isqualified to undergo; contacting the donor to recruit the donor toundergo the procedure.
 55. The method according to claim 54 in which thecentralized system comprises a database, and a data manipulation device.56. The method according to claim 54 in which step of using acentralized system comprises collecting donor data, collecting needdata, optimizing said donor data, and manipulating said optimized donordata and said need data.
 57. The method according to claim 56 in whichstep of collecting donor data comprises receiving data from a discretestorage medium.
 58. The method according to claim 56 in which step ofcollecting donor data comprises receiving data from a data input device.59. The method according to claim 56 in which step of running anoptimization on said donor data to obtain optimized donor data furthercomprises obtaining a prioritization of potential procedures.
 60. Themethod according to claim 54 that is used to control inventory.
 61. Themethod according to claim 54 that is performed without the specificpotential donor present.